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Editor's Desk 



By Chris McEwen 



In the last issue, I gave word on Lee Bradley's Eight Bits 
& Change. He had announced that he was ceasing publica- 
tion. Whatever problems there were have been solved. I am 
happy to report that EB6^ is ccxitinuing. In fact, I have re- 
ceived issues since then. Sony, Lee. 

We have a good bunch of articles in this issue. Paul 
Chidley returns to give us an inside look at the YASBEC 
hardware. Jan Hofland, a new author for us, gives us the first 
part of building an 'Arbitrary Waveform Generator," while 
Jay Sage continues his series on his custom designed home 
contrcdler with a discussion of the 
hardware. Rounding out the hardware ^^a^m^i^^^mm 
side: a brief on a hot new Z280 com- 
puter that Jay found in ^^se during his 
trip to Germany last summer. Tilmarm 
Rey tells us cibout it. 

For you software junkies. Brad Ro- 
driguez tells us how to write an assem- 
bler in Forth. Mind you, he isn't talking 
about writing in assembler — this article 
shows how to write the assembler it- 
self. Great way to build your own cross 
assembler! 

. Al Hawley returns with his series 
on Z80 assembly language program- 
ming, while Terry Hazen picks up 
where Lindsay Haisley left off regard- 
ing lOPs. Add Maft Mercaldo's series 
on the F68HC11, Jay Sage's discussion 
of programming for compatibility, and 
the others, and we have a great issue 
for you! 

By the way, a little "head's up." As 
you know, TCJ is published after- 
hours. Things will be a little rocky for 
the next few months. 1 am going on a 
string on business trips, back-to-back 
from now through December. Hang in 
with us, okay? In the meantime, issues 
53 and possibly 54 may have to fall 
back to the 48 page format. 

Should mention that the response to 
our reader survey has been outstand- 
ing. The responses were all very 
thought out and we will be using them 
to guide TCJs future. I pltm to sum- 
marize after giving the stragglers a bit 
more time. If you haven't sent in your 
survey, please do so. 

One comment came up several 



times: we need a "Letters-to-the-Editor" column. I agree. 

Well, what is a an editorial column without an editorial? If 
you will, please join me for this month's diatribe: 

When is the Public Domain not in the Public Interest? 

This may verge on heresy, coming from one who edits the 
largest journal still supporting CP/M and runs a bulletin 
board dedicated to supplying public domain software, but I 
have a bone to pick. Stay with me just a bit. 

See Editor, page 60 



Reader-to-Reader 



Recent GEnie messages, and issue 
51, have given me much thought about 
TCJ, its popularity, and its "niche" in 
the marketplace. 

What do I like about TCJ? 

I've been getting TCJ since issue 43 
or thereabouts. I originally subscribed 
because of its Forth coverage — being a 
Forth fanatic, I like to keep a complete 
library. But TCJ quickly "grabbed me" 
as much for its hardware-ish articles, 
and its coverage of CP/M. 

TCJ has always been a "read ASAP" 
for me. I invariably start off by reading 
the editorial. The Computer Comer 
(which is usually relevant to my work), 
and Real Computing (which usually 
isn't, but which I enjoy reading — it 
helps me keep up with technology I 
don't normally use). Then, of course, 
the articles. I generally skip the Z-Sys- 
tem articles, since I don't have Z-Sys- 
tem and my CP/M systems have been 
down for a while — but I enjoyed the 
"history of Z-System" in the last issue, 
and thanks to TCJ I expect someday to 
be a Z-system user. 

You summarized it best in your new 
back-cover ad, and in your latest edito- 
rial: I like articles that give me useful 
information, particularly on "how to 
do it" with limited or no resources. TCJ 
is a practical resource for me. I have al- 



ready found many articles of profes- 
sional value, and I expect to find many 
more. 

What of the future of TCJ? 

TCJs target market seems to be se- 
rious hobbyists, novice Forthers, expe- 
rienced CP/M users, and embedded 
systems developers — ^not that there's 
anything magical about embedded sys- 
tems, except that they are the last bas- 
tion of small-scale engineering. But 
hobbyists at TCJs level are vanishing, 
and CP/M, while not dead, is certainly 
not burgeoning, either. Forthere and 
ESPers, of course, have competing 
journals. 

In fact, I may be representative of 
this market. ..which is a problem for 
TCJ, since I'm a member of a dying 
breed! Low-budget hackers, who 
"cross-specialize" in both hardware 
and software, who like to tinker and 
Icnow everything about how their com- 
puters work — ^these are being replaced 
by r\arrowly-focused specialists, "as- 
sembly line" programmers who don't 
know a parse tree from a pear tree, and 
board- swappers who don't know 
which end of the chip is pin 1. Sadly, 
that's where the money is these days. 

How can TCJ grow? 

Tom Peters (an author I highly rec- 
See Reader, page 47 
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YASBEC 

The Hardware 

By Paul Chidley 



Now that you were introduced to YASBEC (Yet Another 
Single Board Eight-bit Computer) in TCJ 51, 1 will try to put 
some more meat on the plate. Some of the ii\formation pre- 
sented here is redundant but necessary if you are meeting 
Yas for the first time. 

For several years I have been an avid 6502 enthusiast. It 
started with my first computer, an OSI Superboard, back in 
1979. (my wife bought it for me) IMHz 6502, 8K RAM, 4K 
Microsoft BASIC-in-ROM and some truly limited I/O. Not to 
mention the 300 baud Kar\sas City tape interface. Through 
the years the system grew and I grew with it. I have become 
a true expert on OSI computers and OS65D. However OSI 
made me a computer orphan in 1980 so recently I figured it 
was time to broaden my horizons. This year, I upgraded to 
CP/M. (I'll go to MesSyDOS when they work the bugs out). 
Problem was, I didn't have any hardware that would run 
CP/M. So like any good midnight hacker, I built some. Luck- 
ily I had a neighbour, Wayire Hortensius, who for years has 
been trying to convince me that 1 should switch to CP/M. 
His knowledge of CP/M and the Z-System help guide me in 
this project. The result of these efforts is YASBEC. 

-Single Eurocard printed circuit board, double 
sided, soldermask. 

-Z180 CPU, PLCC package. 

-Static RAM, 32K to 1MB capacity. 

-32Kx8 (27C256) EPRQM. 

-Optional Real-time clock, with battery backup 
(Dallas DS1216E). 

-DD Floppy controller 

-SCSI hard disk controller 

-2 serial ports 

-1 parallel printer port 

-Buffered backplane cormector 

-Socketed for optional 9511A/8231A Arithmetic 
Processing Unit 

-RAM and I/O addressing by PALs 

-Requires +5VDC and +12VDC 



Paul Chidley is a senior technologist at NovAtel, an Alberta based cellular phone 
company. He's a neophyte ZCPR user, but has been active in homebrewed hardware 
and software design for many years, primarily in the Ohio Scientific and 6502/816 
area. Paul can be reached on GEnie (email address: P.CHIDLEY), by regular mail 
at 162 Hunterhom Drive NE, Calgary Alberta, Canada, T2K 6H5, or by phone at 
(403)274-8891 during reasonable MST hours. 

Wayne Hortensius is, in real life, a software designer also, strangely enough, at 
HcmAld. His involvement with computers began in 1977 when he wirewrapped his 
first computer together around an 8080A. Wayne's been involved with ZCPR since 
1984, on a variety of machines beginning with an Apple 11 clone and ending up, 
most recently with the Z180 YASBEC. Wayne can be reached by regular mail at 
166 Hunterhom Drive NE, Calgary Alberta, Canada, T2K 6H5. 



The board was designed on a single card Eurocard 
(100mm X 160mm) (approximately 4 x 6.5"). In other words, 
small. A Z181 with tsop RAMs and a 4 layer board would 
have resulted in a board half the size but at 5 times the price. 
Given the constraints of double sided and several large DIPs 
a large amount of circuitry was still squeezed onto the board, 
mostly thanks to a large number of surface mount compo- 
nents. 

The Processor 

The processor chosen was the Z180 or 64180Z. The Z80 is 
too limited and the Z181 and Z280 too expensive at 23 times 
the cost of a Z180. The Zilog Z180/Hitachi 64180Z processing 
urut contains a superset of Z80 instructions. There are 12 new 
instructions and many of the Z80 instructions execute in 
fewer clock cycles. The Z180 also contains a timing generator, 
two 16 bit timers, a clocked serial I/O fKDrt, a two channel 
DMA controller, two asynchronous serial ports and a mem- 
ory management unit. There have been several articles in the 
past dealing with this chip should you require more ii\forma- 
tion or programming details. For the YASBEC, a Z180 in a 
PLCC package saves space and provides A19, not available 
on the DIP package. This enables the Z180 to address 1MB of 
RAM without any external bank selects. The system is cur- 
rently running with a clock speed of 9.216 MHz on the 10 
MHz version Z180. Friends at Zilog have mentioned 
12.5MHz, 16MHz, and even a 20MHz version some time 
down the road. Even the 20MHz chip is supposed to be 
available this year, but don't hold your breath. The 20MHz 
version would give us an 18.432 MHz system clock with 
approximately 55ns access times, but it remains to be seen if 
the YASBEC will be able to obtain these speeds reliably. The 
double sided design can be susceptible to noise and other 
problems at such speeds. 

Memory 
YASBEC's RAMs are static, provided by two 32 pin sock- 
ets. These sockets support 32Kx8, 
128Kx8 or 512Kx8 RAMs in 600mil DIP 
packages. Static memory was chosen 
over dynamic for several reasons. Dy- 
namic RAMs are cheaper but require 
several support chips taking up pre- 
cious board space, they are not as fast 
as today's static, and they require CPU 
time for a refresh cycle. With the Z180 
running a 9.216 MHz, access times of 
100ns allow zero wait states with stan- 
dard 'slow' SRAMs. Two 128Kx8 RAM 
chips provide a nice size for banked 
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CP/M at a moderate cx»t of around $30 each. 
The 128fCc8 chips are even available as fast as 
25ns should you want to run the Z180 at 
20MHZ with no wait states. It should however 
be noted that the super fast 128K chips are $100 
but 6 months ago they were $300. By the time a 
20MHz version of the Z180 is available these 
RAMs may be a more reasonable price. Using 
two 32kx8 chips requires a separate PAL to 
inap the RAM in a contiguous block. While the 
ZlSO's memory management unit can map 
physical memory to 64k of logical memory the 
DMA controller uses 20 bit physical addresses. 
Therefor if you lase DMA for I/O in the BIOS 
the DMA must know the physical location of 
the CP/M memory making it important that 
the memory be in one block. 

Monitor 

The system includes a monitor ROM pro- 
gram available at power up if no drives and /or 
software are found or if a key is pressed before 
disk bootup. The ROM is a 27C256 providing 
32Kx8 of space. The first version of the monitor 
occupied 4K. There is room for expansion. Sev- 
eral people have asked why such a big EPROM 
for so little code. This however is a common 
problem today especially in embedded control- 
ler applications. The answer; no one makes 
small, slow EPROMs anymore. A 27C256 is 
cheaper than a 27C64. Of course with the 
MMU (memory management unit) in the Z180 
this is really a non-issue. Once we boot we 
swap out the EPROM, anyway. Using the Dal- 
las DS1216E SmartWatch provides a battery 
backed-up clock for the system. The Smart- 
Watch also serves as a socket for the EPROM. 
While the optional SmartWatch may seem 
piicey at $25, anyone that has to enter the date 
and time m!ore than twice will soon want one. 

Floppy Disk 

The floppy disk schematic is shown in. figure 
1. The controller is a Western Digital WD-1772- 
02 also available from VTI as the VL-1772-02. 
TheT772 (U14) includes everything needed for 
floppy control in a 28 pin DIP except buffers 
and an 8MHz clock. The 8MHz clock comes 
from the oscillator module (U24). The 4MHz 
and 2MHz signals from U23 are used else- 
where by the APU (arithmetic processing unit) 
and not by the floppy circuit. A 74AC04 (U22) 
provides the buffering while a 74 A COO (U18) 
gates motor_on with the drive select lines. The 
four drive select lines come from the control 
register (U20) in figure 2. Note that _FRESET 
and _DDEN also come from the control regis- 
ter. _DDEN selects single or double density 
while PRESET gives us software control of the 
1772 reset line. This allows the software to 
force a reset should the chip become hung 
waiting for a condition too long. e.g. timeout 
waiting for a floppy that isn't there. The major 



disadvantage of the 1772 is that it does not support quad-density (i.e. 

1.44mb) drives or 8" drives. 



Table 1. 






A Description of the 128MEM1 pal. PAL16L8 










1 ————— 

PIN 1 


A19 COMBINATORIAL ; 


INPUT 


PIN 2 


A18 COMBINATORIAL ; 


INPUT 


PIN 3 


A17 COMBINATORIAL ; 


INPUT 


PIN 4 


A16 COMBINATORIAL ; 


INPUT 


PIN 5 


A15 COMBIKATORIAL ; 


INPUT 


PIN 6 


RD COMBINATORIAL ; 


INPUT 


PIN 7 


WR. COMBINATORIAL ; 


INPUT 


PIN 8 


MR£Q COMBINATORIAL ; 


INPUT 


PIN 9 


lORQ COMBINATORIAL ; 


INPUT 


PIN 10 


GND ; 




PIN 11 


10 A7 COMBINATORTAL ; 


INPUT 


PIN 12 


EPRQMCS COMBINATORIAL ; 


OUroUT 


PIN 13 


SRAMICS COMBINATORIAL ; 


OUTPUT 


PIN 14 


SRAM2CS COMBINATORIAL ; 


ompuT 


PIN 15 


MEMRD COMBINATORIAL ; 


OUTPUT 


PIN 16 


MEMWR COMBINATORIAL ; 


OOTPOT 


PIN 17 


lORD COMBINATORIAL ; 


OUTPUT 


PIN 18 


lOWR COMBINATORIAL ; 


OUTPUT 


PIN 19 


BUS_DIR COMBINATORIAL ; 


OUIPUI 


PIN 20 


VCC ; 
















EQUATIONS 




/EPRQMCS 


» /MREQ * /A19 • /A18 • /A17 * /A16 • /AIS 




/SRAMICS 


- /A19 * /A18 * A17 




/SRAM2CS 


« /A19 * A18 * /A17 




/MEMRD - 


/RD ♦ /MREQ 




/MEMWR " 


/WR * /MREQ 




/lORD - 


/RD * /lORQ 




/lOWR - 


/WR ♦ /lORQ 




/BUS_DIR 


= /( A19 * /MREQ * /RD + I0_A7 • /lORQ * /RD ) 




/EPROMCS 


= $0:0000 - $0:7FFF 321c X 8 EproB (27C2SC) 




/SRAMICS 


- $2:0000 - $3:FFFF 12ak x 8 Static Rua 




/SRAM2CS 


° $4:0000 - $5:FFFF 128k X 8 Static Run 




/BUS_DIR 


- Reverse data bus buffer for a 
memory read from $8:0000 - $F:FFFF 
or an i/o read from $80 - $FF 




$PiPFFP 






$6iO000 






$5:0000 


static Ram | 
128K X 8 { 
TC551001PL-100 1 




$4:0000 






$3:0000 


Static Ram | 
128K X 8 1 
TC551001PL-100 1 




$2:0000 






$1:0000 






$0:7FFF 


Monitor Rom | 




$0:0000 


_32k_x_8_27C25«_| 
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SCSI 
A DP5380V or DP8490V (U21) SCSI controller is available 
on the board for hard disks as shown in figure 3. The hard- 
ware is capable of supp>orting up to 7 devices on this one bus. 
Fch: those of you not familiar with SCSI (shame on you) all 
you need is a SCSI drive such as an ST157N and a 50 pin 
libbon cable and you have a hard disk drive on your system. 
Of course you still need some software to talk to it. RSI, RS2 



Table!. 

A Deacrlptia 



of the TUSIO-1 pal. PAL16L8 

— _— ~. PIN Declarations — 



PIH 
P» 
PIH 
PIR 
PIH 
PIH 
PIH 
PIH 
PIH 



PIN 10 

PIH 11 

PIH 12 

PIH 13 

PIH 14 

PIH 15 

PIH 16 

PIH 17 

PIH 18 

PIH 19 

PIH 20 



A7 

A6 

A5 

A4 

A3 

A2 

Al 

AO 

RD 

GND 

«R 

I0_A7 

lORQ 

FPPCS 

NCRCS 

HCRDACK 

FDCCS 

PRINTERSXROBE 

CREQCS 

VCC 



C0t4BIHAI0RIAL 
COMBINATORIAL 
COMBINATORIAL 
COMBINATORIAL 
COMBINATORIAL 
COMBINATORIAL 
COMBINATORIAL 
COMBINATORIAL 
COMBINATORIAL 

COMBINATORIAL 
COMBINATORIAL 
COMBINATORIAL 
COMBINATORIAL 
COMBINATORIAL 
COMBINATORIAL 
COMBINATORIAL 
COMBINATORIAL 
COMBINATORIAL 



INPUT 

INPUT 

INPUT 

INPUT 

INPUT 

INPUT 

INPUT 

INPUT 

INPUT 

INPUT 

INPUT 

OUTPUT 

INPUT 

OUTPUT 

OUTPUT 

OUTPUT 

OUTPUT 

OUTPUT 

OUTPUT 

INPUT 



Boolean Equation Segment 



IQUKnONS 

/CRBQC8 - /lORQ • /WR * /A7 * A6 • /A5 * /A4 • /A3 ♦ /A2 ♦ /Al * /AO 

/PRIHTESSTROBB - /lORO • /VfR * /A7 * A6 • /A5 */A4 */A3 */A2 • Al 

/PPPC8 - /A7 * A£ * /A5 * A4 • /A3 • /A2 • /Al 

/HCKCS " /lORlQ * /A7 * A6 * /AS * A4 * A3 

/HCRDACK- /ICRB • /A7 * AS * AS * /A4 • /A3 * /A2 • /Al * /AG 

/PDCCS - /lORQ * /MR * /A7 ♦ AS * AS * /A4 * A3 

+ /lOHQ * /RD * /A7 * AS * AS • /A4 • A3 
/lO A7 - /A7 



Hot Used 



/CREQCS 

/ntlHIERSIROBB 

/PPPCS 

/NCRCS 

/MCRDAiCK 

/PDCCS 



SFF 

$80 
«6F 
$«8 
$C0 
$58 
$50 
$42 
$40 
$00 



$00 
$40 
$42 
$50 
$58 
$60 
$68 
$70 
$80 



$3F // Z180 Internal I/O 

// Control Register (74hc273) 
$43 // Printer Strobe 

Floating Point Processor 



- $51 // 

- $5F // SCSI 

// SCSI DACK 

- $6F // Floppy Disk Controller 

- $7F // Not Used 

- $FP // Off board I/O 



Off board I/O 



Floppy Controller 



SCSI DACK 



SCSI Controller 



Arith. Math. Proc 



Printer Strobe 



Control Register 



1180 Internal I/O 



and RS3 provide the standard termination required at each 
end of a SCSI bus. Another set must be provided on the other 
'end' of the bus (i.e. the last drive in the chain). The SCSI unit 
number of the YASBEC is coded in software to seven, pro- 
viding jumpers to make this address selectable was not as 
important as saving board space. The only reason emyone 
would need a different unit number would be to put two (or 
more) YASBECs on the same SCSI cable and should anyone 
really want to do that a simple change to the BIOS can give 
one of the boards a new address. Interfacing to the chip is 
done with _NCRCS, _IORD, JOWR and _RESET. The other 
four lines provide feedback for interrupts and DMA control. 
The actual controller is built into the drive, the 5380 is actu- 
ally just a fancy parallel port to talk to the smarts on the drive 
via the SCSI bus. The SCSI transfer protocol is mostly 
handled in software. The 5380 is capable of polled I/O, 
pseudo DMA and full DMA data transfers. It is common to 
find 20 MB SCSI drives for $200 in Computer Shopper and 
other such magazines. At those prices it is hardly worth run- 
ning an old flea market special with half its heads missing, 
even if it was $20. (hi, Hal!) 

Fast Math 
YASBEC is a blend of very new parts and some very old. 
The very old part is the AMD 9511 A/Intel 8231A Arithmetic 
Processing Unit. While this chip has been aroimd since the 
early days of computers it is still in current data books. Why? 
No one has ever built anything to replace it. Current co- 
processors are just that, "co"-processors. They are designed 
to work with their mate but not any others. The APU 
(9511A/8231A) on the other hand is easily interfaced with 
most common 8 bit processors. It features fixed point single 
and double precision (16/32 bit), floating point precision (32 
bit), add, subtract, multiply, divide, conversions and floating 
point trigonometric, inverse trigonometric, square roots, 
logarithms and stack oriented operand storage. The down 
side is that it runs very hot, and costs $150! Almost as much 
as the rest of the board. So why was one included in the 
design? For fast math and Wayne had one. The APU is of 
course optional, YASBEC will do just nicely without one in- 
stalled. But if you need to do sin(x) a thousand times and 
money is no object then there is a socket for an APU, Wayne 
has an astronomy program (sky32) that number crunches 
then plots a graphics display four times faster with the APU 
than without. If nothing else it might be worth the money 
just to show you neighbour how fast your homebrew can 
crunch numbers compared to his PC. 

Address PALs 
Memory and address decoding is done with two 16L8 
PALs, see figure 2. The 16L8 is easy to program and its age 
makes the older bipolar versions available for as little as $2 
with 15ns delays. Should it be needed the 16L8 (16V8) is also 
available as fast as 5ns but at a price. As you can see, PALs 
make the addressing schematic simple, but to see what is 
going on you have to know what the PAL does. Table 1 is a 
listing of the PAL equations and memory map. Given the pin 
definitions and the PAL equations you can see how this PAL 
decodes memory to fit the desired memory map. Having all 
the memory address decoding in one PAL improves the ac- 
cess time needed to talk to the RAM. A 15ns PAL with 100ns 
RAM legally meets the worst case op-code fetch of 118ns at 
9.216 MHz. Where the RAM is located in the 1MB map was 



The Computer Journal / #52 




-L. 8nHz 






Fig. 1 



U24 



DflTfl_BUS(Q.7) 0->,^ 



flDDR_BUS(0tl9)O. 



_FDCCSO 



>CLK 
-Ob- 



74HC74 74HC74 



1, r^Dj a 
>CLK 

-obf 



U23, 



-02MH2 



-04MHz 



08MH2 



.Ff?ESETt> 
_DDENO 




>24 URltE_OnTE 

>22 HRlTE_DnTR 

^16 HOTOR_ON 

^IB DIR.SEL 



■>39 REBOJflTfl 
> 8 INDEX 
>26 TRfiCK_8 



^28 MRITE^PROTECT 




DSIO 



l-KTflL 
2-VSS2 
-VSSl 
*-EXTflL 






fll3|f/lj 

1 Ity 



Fi 



flDDR_BUSI6tl9) 



go 2 




_fPPCS 

>_NCRCS 
>_NCRDflCK 
i.FOCCS 
"_PRINTERSTROBE 



.RESETO 



The Computer Journal / #52 



iuid still is an issue. In the PAL currently being used the 
memory starts at $2:0000 leaving a hole between it and the 
EPROM. Not a big deed, unless an external memory board is 
used and people want the full 1MB (less 32K EPROM) for 
RAM. The joys of a PAL, should it come to that, is we just 
bum a new one. The current memory PAL (UlO) also con- 
trols the data bus buffer direction. To do this it needs to 
know what RAM is on the YASBEC and what is external. For 
now we just chose $8:0000 and up as external but this too can 
change. The 1/0 PAL can also reverse the external data bus 
buffer. The I/O PAL is set up for the Z180 internal I/O from 
$00-$3F, the YASBEC on-board I/O from $40-$7F, and off- 
board I/O from $80-$FF. The I/O PAL contents are listed in 

Serial Ports 
YASBEC is a serial stand-alone system. To get a working 
system you need to talk to the board. In other words, it is a 
complete stand-alone system but you need a dumb serial 
terminal to talk to it. An AT works quite nicely. In fact, many 
CP/Mers I have talked to say that a dumb terminal is a very 
suitable application for an AT. A MAX239 provides TTL to 
RS-232 conversion for all data and signal lines available from 
the ZlSCs serial ports as illustrated in figure 4. The MAX239 
is from the same family as Maxim's MAX232 but with 3 
transmit and 5 receive lines instead of 2 and 2. Unlike the 
MAX232 which only requires +5V the MAX239 requires +5V 
and +12V. The +12V should be readily available since it is 
also needed for any disk drives. The console port has a single 
flow control line labeled RTS coming from the terminal 



(DCE). This definition was taken from the Z180 and is in- 
tended as a hardware handshaking line. The problem is that 
most terminals either don't have hardware handshaking or 
use some other pin for this other than RTS. How you would 
actually use this line, if at all, depends on your terminal. The 
modem port has three control lines, DSR, DTR and DCD. The 
only gotch-ya here is that DCD actually disables the serial 
port hardware when not true. So unless you have a modem 
with a true RS232 conversation mode you will need to set 
jumpers U29 and U30. Some modems have DCD true while 
on-hook in conversation mode, they then set it false after a 
dial command after which it represents the state of the car- 
rier. With such a modem you may hook DCD up as origi- 
nally intended. U30 allows you to use DSR instead while U29 
allows you to short _DCD to ground making it always true. 
Both ports do an adequate job despite the limitations pre- 
sented by the ZlSO's architecture. Note the reset circuit in 
figure 4 has three inputs. C3 and R4 provide a power up 
reset, shorting S2 provides a reset as well as shorting pins 9 
and 10 on J3 the console serial port. 

Printer Port 
The Centronics compatible parallel printer port is your 
standard eight bit output port with hardware handshaking as 
shown in figure 5. Writing to jprinterstrobe+1 latches the 
data in U16, sets _strobe low via address line and U15, and 
clears _int2 if set. Writing to _printerstrobe sets _strobe high, 
the printer acknowledges that the data was received with 
_ack through U15 which sets _int2 low until the next jprin- 
terstrobe. 

See YASBEC, page 42 
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An Arbitrary Waveform Generator 

Using the Harris RTX2001A 



By Jan Hofland 



Introduction 

Vibration control systems for mechanical structural testing 
generally require a programmable signal source. This source 
is used to control the system stimulus during test, which is 
typically a hydraulic shaker table. The usual test setup con- 
sists of a stimulus and several response measurement chan- 
nels. The mechanical motion of the unit under test is meas- 
ured with many accelerometers attached to it. The output 
from the accelerometers goes to an analog to digital converter 
and then through digital signal processing for extraction of 
the pertinent data to characterize the mechanical modes of 
vibration and sensitivities to various stimulii. An important 
attribute of the signal source used in this type of testing is the 
ability to be programmed in real time during the testing so 
that the stimulus can be adapted to the measured responses. 

The purpose of this design project is to demonstrate the 
capability of a programmable waveform generator designed 
around the Harris RTX2001A microprocessor, a Digifal-to- 
Analog Converter (DAC), and a programmable lowpass fil- 
ter. The RTX2001A is used for controlling the DAC sample 
rate {when the next output value is put into the DAC), for 
inputting the data to be output, for putting that data to be 
output into one of two data queues, for controlling the data 
queues and extracting data from the queues to be output to 
the DAC, and for controlling the output lowpass filter cutoff. 
It is also used to generate sinewave data of any frequency up 
to 40 Khz. 

The two data queues are implemented in software. 
They're controlled with a write pointer for inserting values, a 
read pointer for extracting values, an end pointer for deter- 
mining when to loop back to the start of the queue, and a 
count variable to keep track of the number of values in the 
queue. They can be used as a circular buffer where some 
periodic waveform is loaded into the buffer and then the 
data is output from the buffer repeatedly to generate a con- 
tinuous output. The buffers can be configured to operate in a 
ping pong fashion, where data is extracted from one queue 
until it is empty and then it automatically switches to the 
other queue and extracts data from it until it empties, and 
then it stops. Another operating mode is to extract data from 
one buffer until it is empty. 

Sinewave outputs are generated by using a fixed output 
sample rate, a phase accumulator, table lookup of successive 
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values, and interpolation between values in the table. There 
are two basic ways of generating sine values of varying fre- 
quency. One method uses a fixed number of points per cycle 
of the sinewave and varies the rate at which these samples 
are output. The other method is to fix the output sample rate 
and to vary the number of points output per sinewave cycle. 
In other words, vary the phase increment between successive 
outputs. This is the method of sinewave generation used 
here. There is an 800 point sine table representing one full 
cycle of the sinewave. The phase accumulator is incremented 
by a value dependent on output frequency each time a value 
is output to the DAC to determine the next value to be out- 
put. There are two sinewave output modes, one optimized 
for speed and one optimized for accuracy and versatility. In 
the high speed mode, a fb<ed amplitude sinewave is output 
using values directly from the sinewave table. In the 'accus- 
ine' mode there is a second phase accumulator for keeping 
track of the intermediate phase between table points. The 
value output is calculated using the sum of two angles trigo- 
nometric relationships. This mode also allows amplitude 
scaling and D.C. offset adjustment. 

Hardware Overview 

The block diagram for the hardware added to the Harris 
RTX2001A Evaluation Board is shown as Figure 1. It consists 
of the following blocks: 

• An additional 8K x 16 of RAM. Implemented with 
two CY7C185 static RAMs, 45 ns access time. 

• Memory Address Decoder. Implemented in part 
of a GAL 26CV12, 15 ns device. Maps the added RAM 
into memory space 05000-08FFE, hex. 

• Input FIFO, 2K x 16. Implemented with two 
CY7C429 FIFOs, 40 ns access time. Used for command 
and data input. 

• FIFO Read/Write Control. Interlocks the reads 
and writes with their respective empty and full flags. 
Provides write pulsewidth control and interfaces to the 
ASIC bus for reading the FIFO. Implemented in part of 
a GAL 22CV10, 15 ns device. 

• Filter Clock Programmable Counter. Used to con- 
trol the toggle rate of the switched capacitor lowpass 
filter for wide bandwidths. Implemented using a 
74F1779 counter and 74HC273 register. 

• Filter Clock Control. Controls 
filter counter reload, counter ermble, 
and writing to the counter reload 
register. Interfaces to the ASIC bus. 
Implemented with part of the GAL 
26CV12 device. 

• DAC Data Shift Register. Pro- 
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vides parallel to serial data conversion for the output 
DAC. Data is input from the ASIC bus. Implemented 
using two 74HC299 devices. 

• Serial DAC Data Control. Controls data loading 
and shifting and when data is latched into the DAC. 
Implemented using part of the GAL 22CV10. 

• Serial Input DAC. An 18 bit DAC. This device is a 
Burr-Brown PCM61P. 

• Switched Capacitor Lowpass Filter. Used for out- 
put waveform reconstruction. Tuned to a particular 
cutoff by varying the clock frequency. This device is a 
Linear Technology LTC1064-1, 8 pole, elliptic function 
lowpciss filter. 

• Output Buffer. Uruty gain. Implemented using an 
LM6321. 

The schematics are included as Figure 2. The ABEL source 
code for the GAL 26CV12, U3, and GAL 22CV10, U8, will be 
printed in a future issue of TCJ. 

Hardware Detailed Description 

External Input Port 

Commands and data are input to the Waveform Genera- 
tor via the FIFO, comprised of two Cypress Semiconductor 
CY7C429 devices, U9 and UIO. The FIFO provides a 16 bit 
parallel interface by 2048 words deep. Inputs are pulled up 



Listing 1. 

Tha following 16 ■pacific coinmanda have been Implemented: 



NOP 
futSlne 



description 



The next value 



The next 



no operation 

■et up to operate In fast sine mode 

Input Is the frequency. 

2 accuSlna set up to operate In the accurate sine node 

value Input Is the frequency. 

3 setAiqpl sat output an^lltude, In millivolts, for accurate sine 

output mode. The value following this command Is used 
as the output amplitude. This value will be truncated 
to a multiple of 50 mV. 

4 buflAcpO set up to output from buffer In clrculiu: buffer mode 

5 bufLoopl set up to output from buffer 1 In circular buffer mode 

6 plngPongO set up to output In ping pong mode starting with 

buffer 

7 plngPongl sat up to output In ping pong mode starting with 

buffer 1 

8 bufOutO set up to output frcoi buffer until It Is empty 

9 bufOutl set up to output frcn buffer 1 until It Is assgty 

10 IdBuf used to select a buffer and load It with data values. 

Tha next parameter must be the number of values to ba 
loaded, up to 2048, and the msb set If It Is for 
buffer 1. Then the data values ara Input In sequence. 

11 satOffsat set tha offset to be subtracted from the slnewave 

value In accurate slnewava mode. In 100 's of microvolts 
Tha next value following this command Is the offset. 

12 satFllt used to sat the filter cutoff point. The next value 

Input is used for the filter cutoff, range 1 to 40000 
Hi. 

13 getPariod used to Input tha desired sample rate. Tha next 

value Input is used for tha timer period. If in 
either slnewava operating mode, a chaclc Is performed 
to readjust the phase increment to be consistent with 
this period and tha output frequency. 

14 stop disable tijaer Interrupt to stop outputtlng points 

15 start enable tha timer Interrupts to start outputtlng data 

and than go Into a loop to repeatedly check the stale 
data flag in register RX and update tha value in 
scratchpad RH if the stale data flag is set. Continue 
this loop until the timer Interrupt is masked. 

Tha axacution vactors for each of the 16 commands are jsontained in a table 



to +5V via 4.7K resistors. Data is read from the FIFO by the 
RTX2001 via the ASIC bus. The FIFO includes empty and full 
flag outputs. 

FIFO reads and writes are controlled by circuitry in the 
22CV10 PLD, U8. Data is read from the ASIC bus at address 
19 hex. FIFORD is asserted active low if the ASIC bus ad- 
dress GA[2:0]=1, GIO is asserted, GR/W is high, TCLK is 
low and the FIFOMT flag is not asserted. Once asserted, FI- 
FORD stays asserted until TCLK goes high again. This is to 
prevent short cycling when reading the last valid value from 
the FIFO and the FIFOMT flag is asserted. The PLD used is a 
15 ns device, so FIFORD is asserted 15 ns after TCLK goes 
low, worst case. The CY7C429 FIFO has a 40 rw access time, 
worst case, so the FIFO data will be valid on the ASIC bus at 
least 7 ns before cycle completion. In actual operation, typical 
access times of less than 30 ns are common. The reason for 
using TCLK instead of PCLK is that TCLK is being used in 
the PLD for other reasons and that for ASIC bus operations, 
TCLK and PCLK have the same timings. 

FIFO write operations are controlled by the active low 
STROBE input and a flip-flop in PLD U8. When STROBE is 
sensed active low by U8 and if the FIFOFUL flag is not as- 
serted, then US sets FIFOWR active low. When the external 
interface senses that FIFOWR is active, it then may release 
STROBE. The data must be held valid by the external inter- 
face until FIFOWR is deasserted. When U8 senses that 
STROBE is deasserted, it deasserts FI- 
FOWRand strobes the data into the 
FIFO. This interlock protocol ensures 
that only one value is written into the 
FIFO for each STROBE pulse and that 
the write pulsewidths are sufficient for 
the FIFO, The maximum transfer rate 
into the FIFO is limited to one-half the 
system clock rate. 



Digital to Analog Converter 

The DAC chosen for this application 
is a Burr-Brown PCM61P, U14. It was 
chosen primarily for its low cost, at 16 
bit capability, and compact size. 

The PCM61P is a serial input 18 bit 
device and includes an integral ampli- 
fier for current-to-voltage output con- 
version. The orily digital inputs re- 
quired are the serial data input, a dock, 
and a latch enable signal. It accepts 
data most significant bit first, binary 
2's complement coded. Data is clocked 
into the device on the rising edge of the 
clock. The maximum clock rate is 16.9 
MHz, well beyond our 8 MHz system 
clock rate. The latch enable signal actu- 
ally controls which information is 
transferred to the digital-to-aiuJog cir- 
cuitry from the input interface in the 
part. The input clock and the serial 
data stream may be thought of as a 
continuous input. The last 18 bits input 
before the latch enable makes a high- 
to-low transition are transferred to the 
DAC conversion circuitry in the 
PCM61P. The generation of latch en- 
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able is controlled by PLD U8. 

The latch enable signal, DAQ.TCH, is generated by the 
circuitry in PLD U8 based on a 16 bit up/down gray scale 
counter. The counter state variables are Qd, Qc, Qb, and Qa. 
The counter normally is in idle state 0. When a 16 bit value is 
loaded into the DAC data shift register (U6 and U7), it en- 
ables the counter to start counting up in the sequence 0, 1, 3, 
2, 6, ... to the end state 8. The DACLTCH goes high. Now the 
gray code counter reverses direction and starts counting 
down through the states 9, 11, and 10. DACLTCH stays high 
during these states. When DACLTCH is high, the successor 
state of state 10 is the idle state, state 0. When this state 
transition occurs, DACLTCH is held high for the high half of 
TCLK and then deasserted. Thus DACLTCH makes its high- 
tb-low transition one half clock cycle after 18 data bits have 
been clocked into the DAC. 

The DAC output is a voltage ranging from -3V to +3V. 
This output is connected directly to the switched capacitor 
lowpass filter, U15. 

DAC Shift Register 

Two 74HC299 shift registers, U6 and U7, are used to load 
serial data into the DAC. The shift registers are clocked by 
TCLK, the same as the DAC. Normally, the shift registers are 
configured to shift data left, shifting data out of the most 
significant bit (Qh' of U7) to the DAC and shifting zeroes in 
(SR input of U6). New data is loaded into the shift register 
from the ASIC data bus, GD[15:0] by writing to ASIC ad- 
dress 18 (hex). The address is decoded by PLD US to assert 
SERDATLD to the shift register. This write also initiates the 
DAC latch enable control, already described. 

Program mabie Lowpass Filter 

The output from the DAC is filtered by a switched capaci- 
tor lowpass filter, U15. This device is an LTC1064-1 made by 
Linear Technology Corporation. It is an 8th order, clock tun- 
able, elliptic function (Cauer) lowpass filter with +/- 0.1 dB 
passband ripple and 72 dB stopband attenuation at 1.5 times 
the cutoff frequency. The cutoff frequency is 1/ 100th of the 
clock input frequency, so the lowpass setpoint is easily con- 
trolled by changing the clock frequency. All this in only one 
14 pin DIP package! The output from the lowpass filter is 
buffered by a unity gain buffer, U13, to drive the output. 

Filter Clock Control 

There are two mechanisms used to control the filter clock 
frequency. For wide bandwidths, the filter clock is controlled 
by an 8 bit programmable down counter, U5 (a 74F1779) and 
part of PLD U3. The counter is driven by TCLK. When the 
counter reaches terminal count, the filter clock output 
FILTCLK is toggled and the counter is reloaded with the byte 
in register U4. The counter load control signal, CLOAD, is 
generated asynchronously during the low half of TCLK 
when the counter terminal count signal TC is active. The 
design is such that for a load value of zero, FILTCLK will 
toggle every TCLK cycle, for a maximum output frequency 
of 4 MHz corresponding to a filter cutoff of 40 KHz. The 
toggle period of FILTCLK is n+1 times the TCLK period, 
where n is the value programmed into register U4, range 
{0..255}. 

The signal CNTNABL is asserted active low to enable the 
filter clock divider, U5, and the control of FILTCLK by the 
counter terminal count output. CNTNABLis set active low by 



writing to ASIC bus address ID (hex) and cleared by writing 
to ASIC bus address IC (hex). Using this technique to control 
CNTNABL allowed this signal to be set and cleared under 
program control with no additional inputs to PLD U3. 

For values of lowpass cutoff below about 160 Hz, the re- 
quired period exceeds the capacity of the counter. So, for this 
case, one of the RTX2001 internal timers is used to generate 
periodic interrupts. The required period is loaded into timer 
1 and timer 1 interrupts are unmasked. The timer 1 interrupt 
service routine consists of a write to ASIC bus address IF 
(hex) which is decoded by PLD U3 to toggle the FILTCLK 
output if CNTNABL is high. This is probably the most obvi- 
ous hardware/ processor resource tradeoff, where a hard- 
ware counter and latch was added to reduce interrupt servic- 
ing to a more reasonable frequency of about once every 32 
milliseconds, particularly since the filter clock interrupt is at 
a lower priority than the DAC update interrupt. 

External RAI\4 

An additional 8K x 16 of static RAM has been added to 
the EBForth board for code emd data space. The devices used 
are Cypress Semiconductor CY7C185 devices, Ul and U2, 
with a worst case access time of 45 ns. These RAMs have two 
chip select inputs, both of which must be active for accessing 
the chip. One is active high and one is active low. In order to 
minimize any delays that reduce read data access and write 
data setup times, the RTX2001 PCLK is connected directly to 
the active low chip select input, CEl. All other memory ad- 
dress decoding affects the other chip select, CE2. 

The added RAM is memory mapped directly above the 
EBForth board ROM/RAM, starting at memory address 
05000 (hex) through 08FFE. This RAM is byte addressable, 
with Ul containing the high byte and U2 the low byte. PLD 
U3 is used for decoding memory address bits MA[19:12], 
UDS, and LDS to generate the RAM select signals URAMSEL 
and LRAMSEL. 

Miscellaneous Circuitry 

About the only hardware not already described is the RE- 
SET buffer, the NMI pushbutton interface, and the positive 
and negative voltage regulators for the analog circuitry. U16, 
a 74HC132 Schmitt trigger NAND gate, is used for the RE- 
SET interface and as an asynchronous set-reset flip-flop for 
the NMI pushbutton interface. The EBForth board RESET in- 
put is buffered by two sections of U16 and then input to the 
two PLDs, U3 and U8. One section of US is used to invert 
buffered RESET to drive the active low RESET inputs for the 
filter counter load register, U4, the input FIFO, U9 and UlO, 
and the DAC shift register, U6 and U7. 

Two sections of U16 form a cross-coupled set-reset flip- 
flop to debounce the current limited and can, therefore, toler- 
ate being shorted to ground by the pushbutton switch. 
Among other things, it saves finding room for two puUup 
resistors. The output from U16C is connected directly to the 
non-maskable interrupt input on the EBForth board. 

Adjustable three terminal regulators Ull and U12 are 
used to generate the +5V and -5V supply voltages for the 
DAC, the lowpass filter, and the output buffer. 

Software Overview 
The main software loop is a simple two command loop. It 
reads a command from the input FIFO and then executes that 
command. There are 16 recognized commands that are used 
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to set up the Wavefonn Generator for one of 5 operating 
modes, set the lowpass filter cutoff setpoint, set the desired 
DAC sample rate, and load data into the data queues, and set 
up the other parameters necessary. One of the commands is 
then used to start the output process. 

There are supporting words that control how the next out- 
put point is calculated or fetched from the data queue and 
put into the DAC holding register ready for the next timer 



ic 


(not assigned) 


Enable Filter Clock 
Counter 


ID 


(not assigned) 


Disable Filter Clock 
Counter 


IE 


(not assigned) 


T.oad Filter Clock Register 
8 bits 


IF 


(not assigned) 


Toggle Filter Clock Output 



Listing 2. 

Here is the overall operating loopi 



( - ) 
Initialise 
BBGIN 
raadFifo 
doCnd 
ASUN : 



begin an infinite loop 

read a ccmnand from the input stream 

perfoim the caninand 

go do It again 



and here is the canmand execution word: 



doQDd ( n - ) 

DUP caadMsk AHD 
IF 
DROP 

.' Unrecognized 
EI£B parse EXECUTE 



perform the command represented by n 
inaJce sure that the upper 12 bits are zeroes 
if the result of the logical AND is non-zero 
then it is an unrecognized ccnmand and discarded 
Canmand " an error message to the user 
otherwise get an execution vector f rem the 



interrupt. The output sample rate is controlled by program- 
ming it into timer 0. The timer interrupt routine reads 
whatever data has been put into scratchpad register RH and 
writes it into the DAC shift register where it is automatically 
transferred into the serial DAC. Then the service routine dec- 
rements the RX register to set the stale data flag and returns 
to the routine just interrupted. That routine is a loop that 
repeatedly reads the RX register and when it detects a non- 
zero value, it updates the RH scratchpad register with the 
next data value to be output and clears the RX register. 

There are software routines for creating and managing the 
queues in data address space and in code space. One of the 
more useful defining words implemented is one for building 
tables in code space. During compilation, the word table will 
create a table of n words, where n is the top stack value when 
table is invoked. During runtime, calling the table name will 
return the nth value in the table, where n is the top stack 
value. This little word is quite useful for building tables of 
execution vectors, for example. The remaining software is for 
controlling the specific devices attached to the ASIC bus and 
for calculating the interrelated parameters for sinewave and 
other output waveform generation. 

In addition to the operating code, there is some software 
for demonstrating the current capabilities of the Arbitrary 
Wavefonn Generator. 

See Listing 1 for the specific commands which have been 
implemented and listing 2 for the overall operating loop and 
command execution word. 

Software Description 

ASIC Bus Addressable Devices 

The following devices are addressable via the ASIC bus: 



Registers IC, ID and IF are pseudo registers in the sense 
that no data is stored. Instead, a par- 
ticular action occurs by writing to that 
address. The Filter Clock Register, ad- 
dress IE, uses only the lower 8 data 
bits. The upper 8 bits can be anything. 



Sine Wave Generation 

There aie two methods of generat- 
ing sinewave implemented. One of 
them is a direct table lookup, and one 
of them allows interpolation of values 
between the points represented in the 
table. The sine table is an 800 value 
table. The choice of 800 points isn't ar- 
bitrary. First, let's explain about how 
intermediate values of sine arguments 
are derived. The sine of the sum of two 
angles is expressed as follows: 



addr(hax) 


read 




write 


18 


(not assigned) 




DAC Shift Register 16 bit 


19 


Input FIFO 16 bit 




(not assigned) 


lA 


(not assigned) 




(not assigned) 


IB 


FIFO Bn«)ty t Full 
bits and 1 


Status 


(not assigned) 



sin(x + y) - sin(x) • coB(y) + cos(x) • sin(y) 

Now, let the angle y be a small angle. Then we can ap- 
proximate the sin(y) with y, where y is expressed in radians, 
and the cos(y) as nearly 1. So now the sine can be expressed 
as: 

sln(x + y) " sin(x) + y * cos(x) 

If we pick y to be a binary power of 2, then we can calcu- 
late the sin(x+y) with two table lookups, one shift to perform 
the multiply by y and an add. By choosing the interval be- 
tween table points to be y = 1/128 radians, there are 804 
points for one full cycle. This value was rounded to 800 to 
simplify some of the phase increment and sample rate calcu- 
lations, without any loss in accuracy. The values in the table 
have been scaled to be equivalent to a 2 volt RMS output, 
allowing approximately 120 millivolts headroom to the DAC 
full scale output of 3 volts. 

In the Fast sine mode of operation, the variable phase is 
used for phase accumulation and the variable phaseinc is 
used to hold the increment added to phase for each succes- 
sive data point. The Forth word nextPt is used to look up the 
value of sine for the current phase, put that value in the RH 
scratchpad, and then update phase by adding the value of 
phaseinc to it. 

In the accurate sine mode of operatioiv there are more 
software operations performed to determine the output 
value. There are two more variables used to keep track of the 
current value of phase and phase increment. They are del- 
Phase and delPhaselnc. The Forth word newPhase takes care 
of calculating the new phase. It does so by first adding the 
incremental phase increment delPhaselnc to delPhase. This 
value takes care of the intermediate values between table 
points, and is scaled to one part in 800. Anything over 800 
will contribute to the new value of phase, so the next value of 
phase = phase + phaseinc + delPhase/ 800. Now we can look 
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up the sine of the phase variable from the table. Not done 
yet, though. Use the trigonometric identity that cos(x) = sin(x 
+ pi/2) and look up the cosine. 

Now all we must do is to multiply it by a scaled version of 
delPhase (our small angle) and add it to sin(x) to get the sine 
of the exact phase angle. The scaling needs to take care of 
converting to equivalent radians and divide by 128, as I dis- 
cussed earlier. This calculation, and the appropriate scaling 
are performed in the Forth word cosAdj. The other two op- 
erations performed on the accurate sine point before it is put 
into the DAC scratchpad register, RH, is to multiply it by a 
scaling factor to set the output to some multiple of 50 
mVRMS, £md subtract an offset value. The word accuPt per- 
forms this operation. Finally, the word newAccuPt is the one 
that puts the value into scratchpad register RH, clears the 
stale data flag in RX, and proceeds to calculate the new value 
of phase and delPhase. 

Interrupt Routines 

There are three interrupts utilized in this design. The non- 
maskable interrupt is used to stop whatever is happening 
and abort the current operation with the message "Stopped". 
The word pbStop implements this routine. Timers and 1 are 
used to control the DAC sample interval and the filter clock, 
respectively. 

The timer interrupt service routine is called newPt. It 
transfers the value in scratchpad register RH to the DAC shift 
register and then decrements the value in RX to make it non- 
zero. 

The timer 1 interrupt service routine is even simpler. It 
just toggles the filler clock by writing to ASIC address IF 
(hex). The timer 1 interrupt is used for filter cutoff values 
lower than about 160 Hz. 

Parameter Setting Routines 

The word setCutoff takes care of setting the filter clock 
v^ue to some value between 1 Hz and 40 Khz. If the system 
clock divisor is less than 256, then the hardware divider is 
used and the timer 1 interrupt is disabled. On the other hand, 
if it is 256 or greater, then the hardware divider is disabled 
and the divisor is loaded into timer 1 and it is used for tog- 
gling the filter clock. 

There is an inter-relationship between the system clock 
frequency, the desired sinewave output frequency, the num- 
ber of [Ktints represented in one cycle, and the phase incre- 
ment added to the phase variable for each output point. That 
relationship is: 

ph>s«_lncraiBsnt • (#table_polnta/cycle) * (timer period) 

* frequency 

timer Input clock frequency (system clock) 

It turns out that the ratio of #table_points/cycle to system 
clock is 1/10000. This is part of the reason for picking the 
number of points in the table as 800. The word calcint finds 
the timer period given the phase increment and the sine- 
wave frequency. The word calcPhaselnc finds the required 
phase increment given the desired frequency. It uses a mode 
dependent value of minimum timer period. 

There is some interaction between the phase increment 



calculations and the timebase period, particularly for low fre- 
quency operation where the calculated value of phase incre- 
ment is less than one. For this case, the timer period is 
increased until a minimum value of phase increment can be 
achieved. The actual sinewave frequency is calculated from 
the phase increment and the timer period. This value may 
differ slightly from the programmed frequency due to the 
discrete nature of the increment and the period. Such is the 
nature of approximating continuous values with digital rep- 
resentations. 

Queue Building and Management 

Queues are an important data structure used in this de- 
sign. They are used for output data buffering and for simula- 
tion of the input FIFO. The queue building word for data 
space is buildDQ and for code space is buildCQ. Function- 
ally, they behave the same. They're used by putting the de- 
sired size of the queue on the stack, followed by buildDQ or 
buildCQ, followed by the assigned queue name. 

The queue structure consists of a variable to keep track of 
the number of values in the queue, the tail pointer where 
new values are written into the queue, the head pointer 
where data is read from the queue, an end pointer which 
points to the highest storage address in the queue, and 2n 
bytes of storage for the data. When the particular queues are 
defined, the head and tail pointers are initialized to point to 
the first storage location in the queue, the end pointer is set to 
point to the last storage location, and the #values variable is 
set to zero. 

The data locations aren't initialized. They contain what- 
ever random data was left in memory. The word >Cbuf is 
used for putting values into the queue at the tail pointer, 
incrementing the pointer and lvalues, and adjusting the 
pointer of it goes beyond the end pointer. The word Cbuf> 
extracts values from the queue at the head pointer, incre- 
ments the pointer, decrements the #value variable, and ad- 
justs the pointer if it exceeds the end pointer. The word >Que 
uses >Cbuf to put a value into the queue if the queue is not 
full. It returns a false flag if the queue wasn't full or a true 
flag if it was. The word Que> extracts a value from the queue 
if it isn't empty and returns a true flag if it was successful. It 
returns only a false flag if the queue was empty. The word 
#Que returns the number of valid values currently in the 
queue. 

Arbitrary Data Output lUlodes 

There are three output modes implemented using the data 
queues. The word circBuf simply extracts the next value from 
the current read queue and puts it into the RH scratchpad 
register. There is no checking to see if the queue is empty. 
This mode allows repeated output of the same data sequence 
and is useful for generating periodic waveforms. The word 
pingPong implements an output mode where data is read 
from the current read queue and output until the queue is 
emptied. Then the read buffer is switched to the other queue 
and it is read until it empties. When both queues have been 
emptied, it stops. The word onceOut operates in a similcir 
manner, except that it stops after extracting data from the 
first queue. 

We will look at the software source in the next issue.# 
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B. Y. 0. Assembler 

Build Your Own (Cross-) Assembler.. .in Forth 



by Brad Rodriguez 



HEX 
I NOP, 



Introduction 

In a previous issue of this journal 1 described how to 
"bootstrap" yourself into a new processor, with a simple de- 
bug monitor. But how do you write code for this new CPU, 
when you can't find or can't afford an assembler? Build your 
own! 

Forth is an ideal language for this. I've written cross-as- 
semblers in as little as two hours (for the TMS320, over a 
long lunch break). Two days is perhaps more common; and 
one processor (the Zilog SuperS) took me five days. But 
when you have more time than money, this is a bargain. 

In part 1 of this article I will describe the basic principles 
of Forth-style assemblers — structured, single-pass, postfix. 
Much of this will apply to any processor, and these concepts 
are in almost every Forth assembler. 

In part 2, 1 will examine an assembler for a specific CPU: 
the Motorola 6809. This assembler is simple but not trivial, 
occupying 15 screens of source code. Among other things, it 
shows how to handle instructions with multiple modes (in 
this case, addressing modes). By studying this example, you 
can figure out how to handle the peculiarities of your own 
CPU. 

Why Use Forth? 

I believe that Forth is the easiest language in which to 
write assemblers. 

First and foremost. Forth has a "text interpreter" designed 
to look up text strings and perform some related action. 
Turning text strings into bytes is exactly what is needed to 
compile assembler mnemonics! Operands and addressing 
modes can also be handled as Forth "words." 

Forth also includes "defining words," which create large 
sets of words with a common action. This feature is very 
useful when defirung assembler mnemonics. 

Since every Forth word is always available, Forth's arith- 
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metic and logical functions can be used within the assembler 
environment to perform address and operand arithmetic. 

Finally, since the assembler is entirely implemented in 
Forth words, Forth's "colon definitions" provide a rudimen- 
tary macro facility, with no extra effort. 

The Simplest Case: Assembling a NOP 

To understand how Forth translates mnemonics to ma- 
chine code, consider the simplest case: the NOP instruction 
(12 hex on the 6809). 

A conventior\al assembler, on encountering a NOP in the 
opcode field, must append a 12H byte to the output file and 
advance the location counter by 1. Operands and comments 
are ignored. (I will ignore labels for the time being.) 

In Forth, the memory-resident dictionary is usually the 
output "file," So, make NOP a Forth word, and give it an 
action, namely, "append 12H to the dictionary and advance 
the dictionary pointer." 



12 c. 



Assembler opcodes are often given Forth names which in- 
clude a trailing comma, as shown above. This is because 
many Forth words — such as AND XOR and OR — conflict 
with assembler mnemonics. The simplest solution is to 
change the assembler mnemonics slightly, usually with a 
trailing comma. (This comma is a Forth convention, indicat- 
ing that something is appended to the dictionary.) 

The Class of "inherent" Opcodes 
Most processors have many instructions, like NOP, which 
require no operands. All of these could be defined as Forth 
colon definitions, but this duplicates code, and wastes a lot of 
space. It's much more efficient to use Forth's "defining 
word" mechanism to give all of these 
words a common action. In object-ori- 
ented parlance, this builds "instances" 
of a single "class." 

This is done with Forth's CREATE 
and DOES>. (In fig-Forth, as used in 
the 6809 assembler, the words are 
<BU1LDS and DOES>.) See figure 1. 

In this case, the parameter (which is 
specific to each instance) is simply the 
opcode to be assembled for each in- 
struction. 

This technique provides a substan- 
tial memory savings, with almost no 
speed penalty. But the real advantage 
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becomes evident when complex instruction actions — such as 
required for parameters, or addressing modes — are involved. 

Handling Operands 

Most assembler opcodes, it is true, require one or more 
operands. As part of the action for these instructions. Forth 
routines could be written to parse text from the input stream, 
and interpret this text as operand fields. But why? The Forth 
environment already provides a parse-and-interpret mecha- 
nism! 

So, Forth will be used to parse operands. Numbers are 
parsed normally (in any base!), and equates can be Forth 
CONSTANTS. But, since the operands determine how the 
opcode is handled, they will be processed first. The results of 
operand parsing will be left on Forth's stack, to be picked up 
by the opcode word. This leads to Forth's unique postfix 
format for assemblers: operands, followed by opcode. 

Take, for example, the 6809's ORCC instruction, which 
takes a single numeric parameter: 



HEX 

: ORCC, 



lA C, C, 



The exact sequence of actions for ORCC, is: 1) put 1 A hex 
on the parameter stack; 2) append the top stack item (the lA) 
to the dictionary, and drop it from the stack; 3) append the 
new top stack item (the operand) to the dictionary, and drop 
it from the stack. It is assumed that a numeric value was 
already on the stack, for the second C, to use. This numeric 
value is the result of the operand parsing, which, in this case, 
is simply the parsing of a single integer value: 

HEX 

OP ORCC, 

The advantage here is that all of Forth's power to operate 
on stack values, via both built-in operators and newly-de- 
tiped functions, can be employed to create and modify oper- 
ands. For example: 



HEX 

01 CONSTANT CY-FLAG 

02 CONSTANT OV-FLAG 
04 CONSTANT Z-FLAG 



( a "named" numeric value) 



Cy-PLAG Z-FLAG + ORCC, ( add 1 and 4 to get operand) 

The extension of operand-passing to the defining words 
technique is straightforward. 

Handling Addressing lUlodes 

Rarely can an operand, or an opcode, be used unmodified. 
Most of the instructions in a modem processor can take mul- 
tiple forms, depending on the programmer's choice of ad- 
dressing mode. 

Forth assemblers have attacked this problem in a number 
of ways, depending on the requirements of the specific proc- 
essor. All of these techniques remain true to the Forth meth- 
odology: the addressing mode operators are implemented as 
Forth words. When these words are executed, they alter the 
assembly of the current instruction. 

1. Leaving additional parameters on the stack. This is most 
useful when an addressing mode must always be specified. 
The addressing-mode word leaves some constant value on 
the stack, to be picked up by the opcode word. Sometimes 



Figure 1 

I INHERENT 

CREATE 

C, 

DOES> 

C8 

C, 



{ Defines the name of the class) 

{ this will create an Instance) 

( store the parameter for each Instance) 

( this Is the class' common action) 

( get each Instance's parameter) 

{ the assembly action, as above) 

( End of definition) 



HEX 

12 INHERENT NOP, 

3A INHERENT ABX, 
3D INHERENT MUL, 



( Defines an Instance NOP, of class 

INHERENT, with parameter 12H. ) 

( Another Instance - the ABX Instr) 

( Another instance - the MUL instr) 



this value can be a "magic number" which can be added to 
the opcode to modify it for the different mode. When this is 
not feasible, the addressing-mode value can activate a CASE 
statement within the opcode, to select one of several actions. 
In this latter case, instructions of different lengths, possibly 
with different operands, can be assembled depending on the 
addressing mode. 

2. Setting flags or values infixed variables. This is most use- 
ful when the addressing mode is optional. Without knowing 
whether an addressing mode was specified, you don't know 
if the value on the stack is a "magic number" or just an 
operand value. The solution: have the addressing mode put 
its magic number in a predefined variable (often called 
MODE). This variable is initialized to a default value, and 
reset to this default value after each instruction is assembled. 
Thus, this variable can be tested to see if an addressing mode 
was specified (overriding the default). 

3. Modifying parameter values already on the stack. It is occa- 
sionally possible to implement addressing mode words that 
work by modifying an operand value. This is rarely seen. 

All three of these techniques are used, to some extent, 
within the 6809 assembler. 

For most processors, register names can simply be Forth 
CONSTANTS, which leave a value on the stack. For some 
processors it is useful to have register names specify "register 
addressing mode" as well. This is easily done by defining 
register names with a new defining word, whose run-time 
action sets the addressing mode (either on the stack or in a 
MODE variable). 

Some processors allow multiple addressing modes in a 
single instruction. If the number of addressing modes is fixed 
by the instruction, they can be left on the slack. If the number 
of addressing modes is variable, and it is desired to know 
how many have been specified, multiple MODE variables 
can be used for the first, second, etc. (In one case — the Su- 
pers — I had to keep track of not only how many addressing 
modes were specified, but also where among the operjmds 
they were specified. I did this by saving the stack position 
along with each addressing mode.) 

Consider the 6809 ADD instruction. To simplify things, 
ignore the Indexed addressing modes for now, and just con- 
sider the remaining three addressing modes: Immediate, Di- 
rect, and Extended. These will be specified as follows: 

source code aaaembles as 
Immediate: number # ADD, 8B nn 
Direct! address <> ADD, 9B aa 
Extended: address ADD, BB aa aa 

Since Extended has no addressing mode operator, the 
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mode- variable approach seems to be indicated. The Forth 
words # and <> will set MODE. 

Observe the regularity in the 6809 opcodes. If the Immedi- 
ate opcode is the "base" value, then the Direct opcode is this 
value plus 10 hex, and the Extended opcode is this value plus 
30 hex. (And the Indexed opcode, incidentally, is this value 
plus 20 hex.) This applies uniformly across Eilmost all 6809 
instructions which use these addressing modes. (The excep- 
tions are those opcodes whose Direct opcodes are of the form 
Ox hex.) 

Regularities like this Eire made to be exploited! This is a 
general rule for writing assemblers: find or make an opcode 
chart, and look for regularities — especially those applying to 
addressing modes or other instruction modifiers (like condi- 
tion codes). 

In this case, appropriate MODE values are suggested: 



The virtues of structured programming, have long been 
sung — and there are countless "structured assembly" macro 
packages for conventional assemblers. But Forth assemblers 
favor label-free, structured assembly code for a pragmatic 
reason: in Forth, it's simpler to create assembler structures 
than labels! 

The structures commonly included in Forth assemblers 
are intended to resemble the programming structures of 
high-level Forth. (Again, the assembler structures are usually 
distinguished by a trailing comma.) 

1. BEGIN, ...UNTIL, 

The BEGIN, ... UNTIL, construct is the simplest assembler 
structure to understand. The assembler code is to loop back 
to the BEGIN point, until some condition is satisfied. The 
Forth assembler syntax is 



VARIABLE MODE HEX 
: # HODE I 
: o 10 HODE I 
: RESET 30 MODE 1 



The default MODE value is 30 hex (for Extended mode), 
so a Forth word RESET is added to restore this value. RESET 
will be used after every instruction is assembled. 

The ADD, routine can now be written. Let's go ahead and 
write it using a defining word: 



BEGIN, 



more code 



cc UNTIL, 



HEX 

: GEHERAL-OP 

CREATE C, 

DOES> 

C( 

MODE ( -t- 
C, 
MODE ( CASE 

OF C, ENDOF 
10 OF C, ENDOF 
30 OF , ENDOF 
ENDCASE 
RESET ; 
8B GENERAL-OP ADD, 



\ base-(^)code — 

\ operand — 

\ get the base opcode 

\ add the "magic number" 
\ asaamble the opcode 



\ byte operand 
\ byte operand 
\ word operand 



Each "instance" of GENERAL-OP will have a different 
base opcode. When ADD, executes, it will fetch this base 
opcode, add the MODE value to it, and assemble that byte. 
Then it will take the operand which was passed on the stack, 
and assemble it either as a byte or word operand, depending 
on the selected mode. Finally, it will reset MODE. 

Note that all of the code is now defined to create instruc- 
tions in the same family as ADD: 

HEX 89 GENERAL-OP ADC, 

84 GENERAL-OP AND, 

85 GENERAL-OP BIT, 

etc. 

The memory savings from defining words really become 
evident now. Each new opcode word executes the lengthy bit 
of DOES> code given above; but each word is only a one- 
byte Forth definition (plus header and code field, of course). 

This is not the actual code from the 6809 assembler — there 
are additional special cases which need to be handled. But it 
demonstrates that, by storing enough mode information, and 
by making liberal use of CASE statements, the most ludi- 
crous instruction sets can be assembled. 

Handling Control Structures 



where 'cc' is a condition code, which has presumably been 
defined — either as an operand or an addressing mode — for 
the jump instructions. 

Obviously, the UNTIL, will assemble a conditional jump. 
The sense of the jump must be "inverted" so that if 'cc' is sat- 
isfied, the jump does NOT take place, but instead the code 
"falls through" the jump. The conventional assembler 
equivalent would be: 



JR 



-cc,xxx 



(where ~cc is the logical inverse of cc.) 

Forth offers two aids to implementing BEGIN, and UN- 
TIL,. The word HERE will return the current location counter 
value. And values may be kept deep in the stack, with no 
effect on Forth processing, then "elevated" when required. 

So: BEGIN, will "remember" a location counter, by plac- 
ing its value on the stack. UNTIL, will assemble a conditional 
jump to the "remembered" location. 

! BEGIN, ( - a) HERE ; 

I UNTIL, ( a cc - ) NOTCC JR, ; 

This introduces the common Forth stack notation, to indi- 
cate that BEGIN, leaves one value (an address) on the stack. 
UNTIL, consumes two values (an address and a condition 
code) from the stack, with the condition code on top. It is 
presumed that a word NOTCC has been defined, which will 
convert a condition code to its logical inverse. It is also pre- 
sumed that the opcode word JR, has been defined, which will 
expect an address and a condition code as operands. (JR, is a 
more general example than the branch instructions used in 
the 6809 assembler.) 

The use of the stack for storage of the loop address allows 
BEGIN, ... UNTIL, constructs to be nested, as: 



BEGIN, 



BEGIN, 



cc UNTIL, 



CC UNTIL, 



The "inner" UNTIL, resolves the "inner" BEGIN, forming 
a loop wholly contained within the outer BEGIN, ... UNTIL, 
loop. 

2. BEGIN, ...AGAIN, 

Forth commonly provides an "infinite loop" construct. 
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BEGIN ... AGAIN , which never exits. For the sake of com- 
pleteness, this is usually implemented in the assembler as 
well. 

Obviously, this is implemented in the same manner as BE- 
GIN, ... UNTIL, except that the jump which is assembled by 
AGAIN, is an unconditional jump. 

3. DO, ... LOOP, 

Many processors offer some kind of looping instruction. 
Since the 6809 does not, let's cor\sider the Zilog SuperS; its 
Decrement-and-Jump-Non-Zero (DJNZ) instruction can use 
any of 16 registers cis the loop counter. This can be written in 
structured assembler: 



DO, 



mora cods r LCX>P, 



where r is the register used as the loop counter. Once again, 
the intent is to make the assembler construct resemble the 
high-level Forth construct. 



of the jump address field. (After JP, is assembled, the location 
counter HERE points past the jump instruction, so we need 
to subtract two to get the location of the address field.) 
THEN, will patch the current location into the operand field 
of that jump. 

If relative jumps are used, additional code must be added 
to THEN, to calculate the relative offset. 

5. IF, ... ELSE, ... THEN, 

A refinement of the IF,.. .THEN, construct allows code to 
be executed if the condition is NOT satisfied. The Forth syn- 
tax is 



cc IF, 



ELSE, 



THEN, 



ELSE, has the expected meaning: if the first part of this 
statement is not executed, then the second part is. 

The assembler code necessary to create this construct is: 



: DO, ( - a) 
I LOOP, ( a r - 



HERE ; 
DJNZ, 



JP -cc,xxx 



Some Forth assemblers go so far as to make DO, assemble 
a load-immediate instruction for the loop counter — but this 
loses flexibility. Sometimes the loop count isn't a constant. So 
I prefer the above definition of DO, . 

4. IF, ... THEN, 

The IF, ... THEN, construct is the simplest forward-refer- 
encing construct. If a condition is satisfied, the code within 
the IF,. ..THEN, is to be executed; otherwise, control is trans- 
ferred to the first instruction after THEN,. 

(Note that Forth normally employs THEN, where other 
languages use "endif." You can have both in your assem- 
bler.) 

The Forth syntax is 



cc IF, 



THEN, 



for which the "conventional" equivalent is 



JP -cc,xxx 



( the "if- code) 



JP yyy 
xxx: ... ( the "else' code) 

yyy: 



ELSE, must modify the actions of IF, and THEN, as fol- 
lows: a) the forward jump from IF, must be patched to the 
start of the "else" code ("xxx"); and b) the address supplied 
by THEN, must be patched into the unconditional jump in- 
struction at the end of the "if" code ("JP yyy"). ELSE, must 
also assemble the unconditional jump. This is done thus: 

: ELSE ( a - a) T JP, ( unconditional jvunp) 

HERE 2 - ( atack Ita addraas 

for THEN, to patch) 
SWAP ( get the patch address 

of the IP, juiq?) 
HERE SKAP 1 ( patch It to the current 

location, i.e., the 
; next instruction) 

Note that the jump condition 'T' assembles a "jump al- 
ways" instruction. The code from IF, and THEN, can be "re- 
used" if the condition '¥' is defined as the condition-code 
inverse of 'T': 



Note that, once again, the condition code must be inverted 
to produce the expected logical sense for IF, . 

In a single pass assembler, the requisite forward jump 
cannot be directly assembled, since the destination address of 
the jump is not known when IF, is encountered. This prob- 
lem is solved by causing IF, to assemble a "dummy" jump, 
and stack the address of the jump's operand field. Later, the 
word THEN, (which will provide the destination address) 
can remove this stacked address and "patch" the jump in- 
struction accordingly. 

I 17, ( cc - a) NOT SWAP JP, ( conditional jun^ 

HERE 2 - ; with 2-byte operand) 
> THEN, ( a) HERE SWAP t ; ( store HERE at the 

stacked address) 

IF, inverts the condition code, assembles a conditional 
jump to address zero, and then puts on the stack the address 



: ELSE ( a - a) F IF, SNAP THEN, ; 

The SWAP of the stacked addresses reverses the patch or- 
der, so that the THEN, ii\side ELSE, patches the original IF; 
and the final THEN, patches the IF, inside ELSE,. Graphi- 
cally, this becomes: 



IF,(1) ... IF, (2) THEN,(1) ... THEN, (2) 

\ / 

inside ELSE, 



IF,...THEN, and IF,...ELSE,...THEN, structures can be 
nested. This freedom of nesting also extends to mixtures of 
these and BEGIN,...UNTIL, structures. 

6. BEGIN, ... WHILE, ... REPEAT, 

The final, and most complex, assembler control structure 

See BYO Assembler, page 39 



20 



The Computer Journal / #52 



Assembly Language Programming 

Today's Example: ZCNFG 



by A. E. Hawley 



The last two articles were about 'getting started' in assem- 
bly language programming. Now lets take a look at the real 
world of AL programs with a tour of ZCNFG, a public do- 
main program that is sophisticated enough to illustrate many 
of the principles that you can apply to your own programs. 
The main focus will be on a discipline that most of us learned 
the hard way by ignoring it: source program structure. Along 
the way, we'll get introduced to some of the algorithms and 
code structures in ZCNFG. They will help to dispel some of 
the mystery about writing .CFG files for other programs. 

To get the most out of the following discussion, you 
should have the complete source for ZCNFG available for 
study and reference. ZCNFG is available via modem down- 
load from Z-nodes and via mail from ZSUS. 

What ZCNFG Does 

Many commercial programs come with an INSTALL 
utility. That utility customizes the program so that it is 
compatible with your computer hardware and your 
performance preferences. For example, a communications 
program needs to know the port assigned to the modem, and 
the default communication protocol to use. CP/M programs 
that manipulate the screen need installation of the control 
data for your terminal or video display. INSTALL utilities 
configure their target program by modifying data in the 
image of the program stored on disk so that subsequent 
invocations will exhibit the configured performance. Each 
installation program is written by a different author, and no 
two user interfaces are alike. Configuration of public domain 
programs has been traditionally hemdled by reassembly of 
the program or by changing the affected data with a 
debugger or a file patching program like ZPATCH. Both 
require obvious skills on the part of the user as well as a 
certain amount of research to discover what changes are 
possible and what new values are required to achieve the 
desired changes. Again, no two programs are configured the 
same way! 

During early development of ZMAC, ZML, and ZMLIB I 
wrote configuration utilities for each program. Each 



A. E. (Al) Hawley started out as a Physical Chembt with a side line love of 
electronics when it was still analog. He helped develop printed circuit technology, 
and contributed to several early space and satellite projects. His computer experience 
started with a Dartmouth Time-Share system in BASIC, FORTRAN, and ALGOL. 
His first assembly language program was the REVAS disassembler, written for a 
home-brew clone of the Altair computer. As a member of the ZCPR3 team, he helped 
develop ZCPR33 and became sysop of Z-Node ifZ.Hehas contributed to many of the 
ZCPR utilities, and written several. He is author of the ZMAC assembler, ZML 
linker, and the popular ZCNFG utility. 



enhancement could result in a revision of the associated 
configuration program, including the inevitable debugging 
sessions. What a lot of wheel-spinning! The first solution was 
to combine the three programs into one, with a common 
main program to maintain an on-screen menu and three data 
sections to specify what is displayed on the menu. Of course, 
there was also a section to read and write the proper file 
being configured. Since this made a rather large configur- 
ation program, the next move was to make three files of the 
tables. The configuration program then loaded only the file 
appropriate for the target program. Now all I had to do was 
maintain the file of configuration data for each program. 

There are practical pay-offs to well thought out 
organization of the code in a program! 



There is only one configuration program to maintain, and 
debugging caused by changes in the target file is eliminated. 
Now that is worthwhile! 

ZCNFG was bom when I realized that this idea could be 
used with any target program that is organized with configu- 
ration data near the start of the program. Although many 
older CP/M programs were not written that way, more re- 
cent programs adapted or written for Z-system have adopted 
that style. There are practical pay-offs to well thought out 
organization of the code in a program! 

ZCNFG provides a menu driven means of setting default 
options in executable programs, including ZCNFG itself. It 
does this with the help of a configuration file unique to each 
target program. For example, the configuration file for 
ZCNFG is ZCNFG.CFG and that for FF24.COM is FF24.CFG. 

The code in ZCNFG parses the command line to deter- 
mine what file is to be configured, and which .CFG file to 
use. It performs the initialization functions required, and 
provides for an EXIT routine which is the one point at which 
the program returns control to the operating system. A few 
lines showing ZCNFG commands at the bottom of the menu 
display are maintained by code in ZCNFG, rather than by 
data in the .CFG file. 

The .CFG file contains four kinds of 
data for each menu: 

1. Menu Data Structure: a list of 5 
pointers 

2. Case Table: a data record for each 
configuration item 

3. Screen Image: a prototype menu 
screen image 

4. Help Screen: a block of text ex- 
plaining menu items 
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These data structures are described 
in detail in ZCNFG.WS, included in 
ZCNFG17.LBR. You did get it, didn't 
you? 

ZCNFG reads the current values of 
configurable items from the target file, 
uses data from the CFG file to display 
them in the menu, allows the user to 
change them and then updates the data 
in the target file. After exitir\g ZCNFG, 
the program will now behave in accord 
with the newly chosen options because 
the data in its configuration area has 
been rewritten. This process is much 
easier and faster than making the same 
changes with a debugger or file 
patcher. 

Figure 1 shows a typical configura- 
tion menu screen. The user types the 
character associated with one of the 
items on the menu. If that item has a 
YES /NO choice, then the current value is toggled and redis- 
played. If, like item R), a numeric value is required a prompt 
will appear asking for input of that value. The prompt may 
indicate the allowable range of values; only values within 
that range will be accepted. An explanation of the function of 
each configuration choice may be seen by pressing the ? or / 
key. 



Figure 1. 




A TyptamX Conf Iguntltm Msnu 
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R) Return nunber of files found in register number 10 


S) include Systaai files in the sesrch 7 


NO 


T) Terminator following DIR/DO for found files 


is > 


V) view console screen with Paging enabled? 


YES 


W) auto-Hildcardlng in the search argument? 


YES 


0) Limit default drives to logged-in ones? 


NO 


1) display drive # headers for found files? 


NO 


2) Use NDR to control search? 


YES 


3) Wheel control? YES 4) NDR for wheel user? 


NO 


ZCNFG INSTALLATION CONTROL 




X or Esc ''Save changes k eXit Q,'C "Quit with no 


changes saved 


/ or ? "Explain Options > or . "Next Henu < or 


, ^Previous Menu 


Which choice? 





Listing 1. 







PROGRAM CODE 


ICNPG: 


JP 


BEGIN 


I3MARKI 


DB 


•Z3ENV' 




DB 


1 


Z3BNVI 


DH 







DW 


ZCNFG 



; identifies program as ZCPR3x utility 
; external environinent 
;thls axldress set by Z3INS or ZCPR33/4 
• cciifiatlble with type 4 envlrcment 



; configuration block for THIS program. 

CNFGID: DB 'ZCNFG' ;ID string, null teminated 

DS 4,0 ;max 8 char plus null terminator 

ALTUSR: DB -1 ;-l - search default user 

; additional configuration items go here 



Functional Organization 

An AL program is usually organized as shown in figure 2. 
This arrangement, though common, is certainly not manda- 
tory. Experience has shown that the program header should 
occur first in the source file, and that it is convenient to put 
most of the data items at the end of the file. A program like 
ZCNFG which is expected to be executable after assembly/ 
link must observe certain conventions at the start of the code 
in order to be compatible with the operating system. Like- 
wise, the position of the block of configuration data is predi- 
cated on the use of ZCNFG or on convenience when using a 
debugger to set default values. 

At the very start of a program is the Program Header. This 
header is in two basic parts: textual in- 
formation that identifies the program 
to the programmer, and definition of 
quantities to be used by the assembler 
and linker. 

The textual information takes the 



form of comments in which each line starts with a semicolon. 
It is ignored by the assembler; if you leave it out you are only 
cheating yourself (or others) of some information. 

Quantities used by the assembler and linker defined here 
are Constants, Public Symbols, and External Symbols. The 
assembler does not care about the order in which these 
symbols are declared, as long as the statements themselves 
are correct. You will note, however, in 
the ZCNFG source code, the 
.REQUEST statements which name 
libraries like Z3LIB, SYSLIB, and 
others. The order in which these 
statements occurs is important! The 
linker searches those libraries in the 
order in which they are named. These 
.request statements are a substitute for 
including the library names in the 
linker command tail. ZMAC, M80, and 
the SLR assemblers recognize the 
.request statement; others may not, in 
which case such statements must be 
removed and the libraries included in 
the linkers list. If you get the order wrong the linker will 
complain to you about 'undefined symbols' or unresolved 
externals. 

Constants used by the assembler are defined by EQU 
statements. Such statements might, for example, define AS- 
CII constants like CR and LF. This is a convenient place to 
define version number and version date. Other constants de- 
fined this way in ZCNFG are standard system addresses like 
the targets of the WB and BDOS jumps in page and the 
system buffers (FCB and TBUF) in page 0. For ZCNFG, the 
offsets to certain important data in the target program are 
defined this way. 

Symbols which are to be shared with other program mod- 
ules are declared PUBLIC; those which the current program 



Listing 2. 






STARTUP 


BEGIN: LD 


(STACK), SP 


LD 


SP, STACK 



;save system stack pointer 
;8et up local stack 
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Figure 2. 



needs from some other module are declared EXTemal. The 
assembler places PUBLIC symbols and their address value 
in the .REL file. It also places EXT sym- 
bols in the REL file along with infor- 
mation about where in the current 
module each symbol is used. The 
Imker, after it knows the values for all 
the PUBLIC symbols for all the mod- 
ules being linked, puts these values in 
the appropriate EXT locations. For each 
PUBLIC symbol in the current module 
there may be many EXT declarations in 
other modules. Similarly, for each EXT 
symbol in the current module there 
must be a matching PUBLIC symbol in 
one of the other modules. 

The program header is also a good 
place to define macros that will be 
used in the program. ZCNFG defines 
three such macros in this section. Mac- 
ros do not produce code at this point; 
actual code is only produced when the 
macro is named later on in the pro- 
gram as an instruction. 

When programs get complex, the 
defiiutions section can get large 
enough to be an inconvenience in edit- 
ing and reading the source file. You 
can make things appear a little simpler 
by transferring as much of this section 
as you like to a separate file, then in- 
cluding it in the assembly source with 
a MACLIB or INCLUDE statement. For 
exjimple, if all the header except the 
operung comment lines of ZCNFG had 
been removed and placed in a file 
called ZCNFGHDR.LIB, then the fol- 
lowing statement would take its place 
in the source file; 



tended to be configured using all the facility of ZCNFG, 
there must be an immediately following block of header and 



INCLUDE ZCNFGHDR 

Assembly language code, as you 
will have observed already, includes a 
great detJ of excruciating detail which 
for most people interferes with com- 
prehension of the main program flow 
and functions. The INCLUDE provides 
a way of 'hiding' such detail. Many 
HLLs also provide the same facility, 
and for the same reason! The assembler 
doesn't care which way you choose; 
the code produced is the same either 
way. 

Program Code 
Most program code starts with a JP 
instruction whose target is the actual 
start of program related code. This 
strategy permits converuent inclusion 
of a data area at the beginning of the 
program. If a program is intended to 
be a Z-system utility, it must start with 
the standard ZCPR header. If it is in- 



PROGRAH STRUCTURE 



PROGRAM HEADER 

Program comnenta - Hama, Author, Date, Puxpooe, Rafersncea 
Program definition* (<variable> EQU <v«lue>) 
External declarationa (in Z3LIB, SYSLIB, etc.) 
Public declarations 

PROGRAM CODE (see listing 1.) 

JP START (or RST 0, DW START or RET, DW START) 
Z34 ENV Structure 
Configuration Block 

STARTUP (see listing 2.) 

Check for ZSO cpu, exit with message if not. 
Save SP and set local stack. 

ENVIRONMENT INITIALIZATION (see listing 3.) 

Identify OS parameters of importance to the program 

OS version - CP/M 2 or 37 ZRDOS7 ZSD0S7 Z3PLUS7 ..etc. 
CCP identification - CP/M or ZCPR7 Which version of ZCPR7 
Is DateStaiq>ing Available? ffhich kind? (DS, ZSDOS, CPM4-) 
Is a Real Time Clock available (other than D6, ZSDOS, CPMf)7 
Initialize the ZCPR and VLIB Environment if appropriate. 
Error Exit if OS support is inadequate 

HEIf (see listing 3.) 

Parse CL for help request. 

Display HELP screen if required by a CALL to a Print_Iielp routine 
Return to OS by a junp to PROGRAM EXIT if help was printed, 
Else continue with . . . 

PROGRAM INITIALIZATION (see listing 3.) 

Copy configuration data from the CFG block to « data buffer or 

final destination- 
Parse cciranand line for options and update those in cfg data buffer. 
Allocate memory usage 
Initialize buffers and data values 
Initialize FCBb 

Open input file(s) if appropriate 
Open output file(s) if appropriate 

MAIN PROGRAM (see listing 4.) 

Here is the place for your program to "do it's thing". 



PROGRAM EXIT 

close any open files 

relog current directory if appropriate 
Restore iuiy changed OS parameters 
Restore callers stack pointer from saved value 
exit via RET if CCP has not been overwritten, 
else exit via JP or RST 0. 

SUBROUTINES 

Print_Help is a called routine so that it can be invoked 
from anywhere in the program without aborting to the OS. 

Initialization routines are conveniently placed here 
and called from the initialization section to avoid 
cluttering up the main flow of the program. 

Special file handling routines 

Screen management routines 

Low level functions like data format conversion routines 

BDOS function routines 

DATA (Initialized) 
Messages 
Screen Images 
File Control Blocks 
Initialized vcuriables 

DATA (Uninitialized) 
Stack space 
Callers stack pointer 
Copy of configuration data 
Uninitialized variables 
Buffers 
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data for use by ZCNFG. CFG files do not start with a JP 
instruction because when assembled they are data files and 
are not executable. In fact, they start with a RST instruction 
which simply executes a warm boot and return to the CCP. 
This protects the file from inadvertent execution. See Listing 
1 for an example. 



Listings. 






■ 


aSUf t INITTAI.TZATIOH 1 


CALL 


IHIT 


;Bet current du. Teat for Z3 


ID 


DE.SIGHOH 




CALL 


TYPLIH 




CALL 


HBU 


; provide help if requested t quit 


CAIJ. 


PGMINI 


;Get file spec frcm FCB, open file 
;idx>rt with mesBage if bad file spec 


CALL 


PILINIT 


(•identify t load the overlay file 


CALL 


SCR_LD 


;loeui screen iiiiage(8) 



Startup 

This is, apart from the initieil jump, the beginning of the 
executable code in the program. In ZCNFG, the label at this 
point is BEGIN:, and the initial jump instruction is JP BEGIN. 
If you are concerned about the possibility of your program 
being executed on a CPU that doesn't support the code in 
the program (i.e. Z80 code and an 8080 CPU), then here is the 
place for code that identifies the CPU. If the wrong CPU is 
present, then the code must immediately exit. An error mes- 
sage is appropriate. The code up to this point must use only 
instructions supported by both CPUs (8080 code in this case). 
Remember, we are talking about the instructions in machine 
language generated, not the assembler mnemonics used! For 
example, a ]P instruction will execute 
properly on both CPUs but a JR in- 
struction will only be recognized by 
the Z80. Several public domain pro- 
grams use this kind of test; ZCNFG 
does not. 

We are now (almost) ready to start 
computing. First, we have to make 
sure the Stack Pointer is being properly 
managed. This one item is probably re- 
sf>oiuible for more system crashes than 
all others combined! When your pro- 
gram starts executing, the stack cur- 
rently assigned is that of the program 
(usually the CCP) that called it. That 
stack may or may not have enough 
room to support the requirements of 
your program. If it is too small, your 
program is guaranteed to crash the sys- 
tem. If you prefer not to play russian 
roulette, do like ZCNFG dees at the 
first opportunity; save the SP. Define a 
local stack within the program. Listing 
2 shows an example. 

Help and Initialization 
Two initialization sections occur in ZCNFG. The first is 
the CALL INIT instruction. INIT installs the current version 
number and date in the signon message, then sets a flag if 
ZCPR3/33/34 is available. This portion of the initialization 
provides information for the following signon message dis- 
play and the call to the program HELP function. When the 



HELP routine determines that a help screen is not appropri- 
ate it simply returns; otherwise, the help screen is printed 
emd the program is terminated by a jump to the main exit 
routine (its name in ZCNFG is QUIT:) which restores the SP 
and returns control to the CCP. 

The second initialization section comprises the calls to 
PGMINI, FILINIT, and SCRLD. 
PGMINIT performs a number of 
housekeeping tasks, as outlined in fig- 
ure 2. Here, the target filesp>ec is deter- 
mined and the file is opened for read- 
ing. The default name for the CFG file 
is defined if it isn't present on the com- 
mand line. 

FILINIT reads the first page of the 
target program. If it's a ZCPR34 type 4 
program, then a second read is per- 
formed to get the real first page (256 
bytes) of the program where the configuration data resides. 
This data is loaded into a 256 byte buffer named TGTBUF. It 
then looks at offset lODh in the configuration page for the 
name of a CFG file. FILINIT selects the first CFG filespec 
from the following prioritized list: 

1. the second argument in the command tail 

2. the i\ame (if any) from the target configuration page 

3. the default defined in PGMINIT 

The CFG file is loaded into memory starting at the first 
unallocated location above ZCNFG. The address of the start 
of this free memory is stored in a variable labeled OVRLAY:. 



Listing 4. 


MAIN PROGRAM 






; select ( set 


options interactively 




;Thia is a loop whose exit la 


one of the cases 




SETOPT: CALL 


Z2CIS 


; clear screen 




in 


DE,(SIMAGE) 


;-> screen image 




CALL 


TTfPLIN 


;di8play the screen 




LD 


A, (Z3MSGF) 






OR 


A 


;ZCPR3 present? 




JR 


Z,N0T1Z3 






CAT.T, 


AT 


;cur8or positioning if Z3 




AIPRPT: DB 


19,1 


; prompt near screen bottcto 




N0T1Z3: LD 


DE,PRMPTO 


;-> prompt line(s) 




CALL 


TYPLIN 


; display user prompt 




;get user input. Make changes 


as requested, update the 




; screen image 


and the target configuration block. 




GETINPi CALL 


CIN 


;wait for i get user input 




JR 


Z,GETINP 


;z - no input yet 




CALL 


UCASE 


;malce upper case 




CALL 


ISPRINT 


; printable character? 




CALL 


Z,C0UT 


;echo it if so 




LD 


HL, (CASTBL) 


;->ca8e table 




CALL 


MCASE 


;do case, ret to here if no exit | 


JR 


C.GETINP 


;on bad cmd, repeat prcopt 


& retry 


JR 


SETOPT 


; redisplay screen it prompt 


after update 



This location is also labeled $MEMRY:. When ZCNFG was 
assembled and liiJced, the linker stored the location of free 
memory there. The label '$MEMRY' is reserved for this use by 
most modern linkers. The other label for this location, 
OVRLAY, refers to the same quantity and is used for seman- 
tic and debugging convenience. 

See Assembler Programming, page 56 
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The NZCOM lOP 

A Background Clock Display 



By Terry Hazen 



Introduction 

I've always wanted to have a background clock display 
available on my terminal. While I was working on the RSX 
version of the HP14 integer RPN calculator, Joe Wright com- 
mented that it would really make more sense to do a calcula- 
tor as an lOP. I hadn't really thought much about lOPs be- 
fore. My Ampro BIOS didn't support lOPs and I hadn't seen 
much written about them. Since NZCOM makes it so easy to 
create an operating system that can include an I OP, I thought 
it would be fun to learn more about them by adapting HP14 
as an lOP calculator. I did (see HP14.LBR, on your favorite 2^ 
node), and I liked it so well I decided to try integrating a 
background clock display into the operating system as an 
lOP module. 

In this first of two articles, I'll present CLKIOP, a 
background NZCOM lOP clock display module. Next time 
I'll present lOPLDR, a general-purpose 
NZCOM lOP module loader that is 
combined with an lOP REL module 
and some module-specific routines to 
create a stand-alcme COM file that will 
load, control and remove the lOP 
module. We'll use it to create the 
stand-alone lOP clock display utility 
IOPCLK.COM. 

Before we look at the I OP dock, 
though, let's take a quick look at the 
two most common ways of extending 
the CP/M operating system, the RSX and the lOP. Both RSX 
and lOP modules are used to extend the CP/M operating 
system in various ways. They can both intercept and modify 
BDOS OT BIOS functions and even provide new BDOS or 
BIOS functions. 
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trying to write small punched-card batch-processed ALGOL programs. He got his 
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and building varied types of hardware and software projects, not all of them com- 
puter-related. His recent software projects include the HP and HPC RPN calcula- 
tors and the REMIND appointment reminder utility as well as upgrades to his 
SCAN text file viewing utility and ZP file/disk/memory record patcher. He may be 
reached by voice at (408)354-7188 or by message on Ladera Z-node #2. His address 
is 21460 Bear Creek Road, Los Gatos, CA 95030. 



The RSX 

The RSX (Resident System Extension) is a structure that is 
loaded under the CCP and protected from being overwritten 
by warm boots. The RSX can be easily loaded or removed to 
provide specific functions on a temporary or semi-permanent 
basis and can be made relatively large if required. Since an 
RSX is loaded below the protected CCP, however, the avail- 
able TPA space is reduced by the size of the RSX plus the size 
of the CCP. The extra amount of space an RSX takes can 
make it relatively unattractive for more permanent uses in 
systems that are short on TPA. 

Biidger Mitchell covers the details of the standard 
Plu'Perfect CP/M 22 RSX structure in his Advanced CP/M 
column in TCJ 34. Al Hawley describes ZREMOTE, a practi- 
cal RSX application, in his Getting Started in Assembly Lan- 
guage column in TCJ 50. 



Figure 1. 

Tracing an NZCOM BIOS I/O Call 

■I — > CBIOS Jump Table — > CBIOS I/O Routine 

I 
+_| — > lOP Input Jump Table — > (Intereepta) — > lOP Output Juop Table — K 

I I I 

I H NZBIOS Auxiliary lOP Jun^ Table < K 

H NZBIOS Main Jvunp Table < 



I 
Application! Program BIOS I/O Call K 



The lOP 

The lOP (Input/ Output Package) is another way to extend 
the CP/M system. In contrast to the RSX, an lOP module is 
dynamically loaded into an lOP buffer in high memory and 
reduces the available TPA space only by the size of the lOP 
buffer itself. It works by intercepting 
and modifying BIOS I/O calls. Its size 
is limited to the currently defined size 
of the lOP buffer, although with 
NZCOM, that may be easily changed 
as required. 

The standard lOP structure pro- 
vides two jump tables to make it easy 
to intercept and modify of BIOS I/O 
calls (Figure 1.) Calls are passed from 
the main NZBIOS jump table to the 
lOP input jump table, which directs 
them to the lOP output jump table, 
which in turn directs them back to an 
auxiliary NZBIOS lOP jump table, 
which directs them to the CBIOS main 
jump table, where they are fir\ally 
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passed on to the actual working routines in the CBIOS. 
Whew! Intercepting a BIOS I/O call in the lOP module is 
easy. You only have to change the call's target address in 
the lOP input jump table to point to a local lOP interception 
routine. 

The standard lOP structure also has several additional 
entry points to optional custom routines that can provide 
other I/O services in a standard way: 

The STATUS routine at IOP+0 can be used to tell the 

calling program information about the current lOP 

module. 

The SELECT routine at IOP+3 can be used to assign 

physical to logical devices or to deselect the current 

lOP module. 

The NAMER routine at IOP+6 can return a pointer 

to the name of the lOP module. 

The lOPINIT routine at IOP+9 is always called by 

the loader during the loading process and performs all 

required lOP initiation. 

The NEWIO routine at IOP+21h can be designed to 

install new I/O drivers. 

Rick Conn covers the original I OP structure and his in- 
tended uses for each of these lOP routines in 'ZCPR3 The 
Manual' (New York Zoetrope, 1985). p212ff. 

In NZCOM, Joe Wright extended the original lOP con- 
cept to include the lOP module as a preprocessor for BIOS 
I/O calls and designed a new standard lOP data structure 
to make the lOP easier to use. He also extended the stan- 
dard lOP structure to support several more optional but 
useful I/O routines especially designed for I/O redirection: 
COPEN at IOP+24h and CCLOSE at 10P+27h can be 

used to open and close a file specified as the CON: disk 

fUe. 

LOPEN at I0P+2Ah and LCLOSE at I0P+2Dh can 

be used to open and close a file specified as the LST: 

disk file. 

These routines can be designed to control files used by 
lOP I/O redirection packages such as Alpha Systems' 
NuKey, BPRINTer and RECORDer. 

The lOP Clock 

A good background clock display lOP routine should 
run constantly in the background, updating a date and time 
display somewhere on the terminal screen while keeping 
out of the way of foreground application utilities. But 
where should the clock display go? I first tried putting it in 
the upper right comer of the screen display area and imme- 
diately ran into problems because it took so long to con- 
stantly save and restore the current curscn: position. It also 
turns out that GETCUE^ the VLIB routine to report the cur- 
rent cursor position, only works with one type of terminal 
and isn't a general routine. For example, it doesn't work at 
all with ANSI terminals. Applications programs also 
bumped the clock display off the screen from time to time 
and it often ended up being overlaid on a part of the appli- 
cations program display screen. All Ln all, it wasn't very 
satisfactory. Qose, but no cigar. 

Then I made the discovery that all my terminals had 
some form of host computer message field on the top line 
of the display, just above the regular display area. As it 
turned out, the message field proved to be an excellent 
place for a clock display. On the minus side, not all older 
terminals have message fields. Also, since each terminal 



Listing 1 

Module: 
Author! 
Date; 
Veraion s 



dJCIOP 
Terry Hazen 
03/22/91 
1.0 



Note: This lOP module conforms to Joe Wright's Standard 
Z-Syatem I/O Package structure, version 4.0, Hay 4, 1989. 



Equates 



bell 
on 



equ 
equ 



07 
Offh 



He need one library routine: 



.request 
ext 



syslib 
ma2hc 



The following jumps and package ID are a fixed data 
structure and cannot be changed if this package is to 
work with standard losuiers and SHOW programs: 

lOF Input Jun^ Table 



iop: jp 


zero 


; Internal Status Routine 


(lOP+OOh) 


jp 


select 


; Device Select Routine 


( IOP+0 3h) 


jp 


zero 


; Device Name Routine 


(IOP+0«h) 


jp 

• 


lopinit 


; Initialize IOP 


(IOP+09h) 


r 

cons : jp 


const 


; Console Input Status 


(lOP+OCh) 


jp 


iconin 


; Console Input Character 


(lOP+OFh) 


jp 


conout 


; Console Output Chau:acter(I0P+12h) 


jp 


list 


; List Output Character 


(I0P+15h) 


jp 


punch 


; Punch Output Character 


(I0P+18h) 


jp 


reader 


; Reader Input Character 


(lOP+lAh) 


jp 


listst 


; List Output Status 


(lOP+lEh) 


; Optional routines (not 


used by lOPCLK) 




jp 


zero 


; I/O Driver Installation 


(I0P+21h) 


jp 


zero 


; Open CON: Disk File 


(IOP-l-24h) 


jp 


zero 


; Close COHs Disk File 


(I0P+27h) 


jp 


zero 


; Open LST: Disk File 


(I0P+2Ah) 


jp 


zero 


; Close LST: Disk File 


(I0P-f2Dh) 


r 

; I/O package 


identification 




1 

db 


'23IOP' 


; NZCOM IOP ID 


(IOP+30h) 


db 


'lOPCLKlO' ; Package name (8 bytes 


|(IOP+35h) 



I(V Output Jxmp Table. 



(I0P+3Dh) 



The targets of the following seven jmopi are filled in by 
the lOPIHIT routine, always called by any IOP loader, to 
point to the NZBIOS juiq> table. 



const: 


jp 





conin: 


jp 





conout: 


jp 





list: 


jp 





punch: 


jp 





reader: 


jp 





Ustst: 


jp 






The preceding jumps and package ID MUST remain in their 
present positions to maintain the integrity of the lOf 
structure . 

The main body of the 10 Package starts here. Code and 
structure from here on is free-foia and may be aovad 
about as you wish: 



lOPCUC configuration area. (IOP+52h) 

Configuration data is normally copied frcai the 
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ooBflguratlon axaa of tha IWCUC.COH loader program. If 
••■•■bllng this coda to a R2L fila and ualng HSCOM or 
JEnm to load it, conflgura thla araa dlractly In tha 
aouroa codas 

baapt db ; Oil>qouiid conaola ball aa hourly alara 

aaconda:db ; OM-lncluda aaconda In clock dlaplay 

tiaat db ; OH-uaa 12hr tljaa 

aaclkt dw ; Addcaaa of ZSD06 clock rcutlna 

String aant to tarmlnal to place a aeaaage at a apecifie; 
point in a taiainal aaaaage field. Tha apecial character 
uaed to tazslnata the terminal meaaage ia located at 
(0 tarminationa are for PSni) 



term: 



da 
db 



tarmendidb 

f 

apacaat db 



8 ; Prefix for terminal mag - 8 bytea max 

; Termination 

; Terminal naaaage termination character 

; Number of apacea to the beginning of 

; the clock dlaplay 



nw clock dlaplay buffer la a part of the terminal 
maaaaga. 'mo', 'da', etc, are filler bytea to ahow data 
and time locationa. They are replaced with the currant 
data and time bytea irtten the clock dlaplay la updated at 
UPDAIM. 



dmoi 


db 


'mo/ 


ddai 


db 


'da/ 


dyri 


db 


'yr 


dhr: 


db 


'hr: 


(tad: 


db 


'mi' 


colon: 


db 


': ' 


dae: 


db 


'ae' 




db 





; 

; Intercept CONIN 


iconin: 


call 


cona 




or 


a 




Ir 


na,e 



; Set to to end with lalnutea 
; Termination 



; Check for pending character 
na,eonln ; Yea, get It right away 



call clock ; 
Ha have time, update clock dlaplay 

jr iconin ; Check for another character 

clock: Id de,yr ; OE>clock buffer 

Id hl,(saclk) ; HL-addreaa of ZSD06 clock driver 

Id c,0 ; Set read clock function 

call jphl ; Read clock into our clock buff er 

Id bc,8e ; Point to current aeconda 
Id hl,OBa ; Point to old aeconda 

chktlm: call aecchk ; Check for change (min or aec) 
ret I ; Quit if no change 

Update clock dlaplay buffer after Initial check to aee if 
aeccmda have changed, atarting with minutea (or hours) and 
working backwards toward years. Convert each chiuiged byte 
frca BCD in the clock buffer to ASCII in the display 
buffer, quitting at tha first unchanged date/tine byte. 



Point to display buffer minutea 
Update if changed minutes 
Quit if no change 

Point to display buffer hour 
Update if changed hour 
Quit if no change 

Do change of hour housekeeping 
Point to display buffer day 
Update if changed day 
Quit if no change 

Point to display buffer month 



updatm: 


Id 


de,dmi 




call 


check 




Jr 


I, display 


updath: 


Id 


de,dhr 




call 


check 




Jr 


1, dlaplay 




call 


hour 




Id 


da,dda 




call 


check 




Jr 


a, dlaplay 



Id 



de,dmo 



requires a different terminal control string to identify such a 
message and the required string is not included in the 
ZCPR3 Z3TCAP, you have to do a little homework with 
your terminal manual to find the correct sequences. 

On a WYSE30/50, for example, to place the clock display 
in the right comer of the host terminal message field, we 
need to send the following string (including the 28 spaces): 



BSC,'F 



mm/dd/yy hh:aK:as',CR 



To do the same thing on a WYSE75, we need to send the 
following string (including the 22 spaces): 



BSC,'[>+\ 



ami/dd/yy hhiam:ss\' 



Reading the Clock 

To keep things as universal as possible, I decided to use 
the ZDDOS/ZSDOS clock as my time and date source. Since 
the lOP clock is essentially a part of the BIOS, we can't take 
the easy way out and use the standard ZSDOS call to read 
the clock. While we could take advantage of ZSDOS support 
for re-entrant 6DOS calls, this would require us to save and 
restore a 147 byte DOS data area, which would slow us 
down accordingly. 

Luckily, there is an easier and faster way. Since ZSDOS 
stores the address of the ZSDOS clock driver at DOS+16h, 
we can easily find the address of the clock driver when the 
lOP clock is first loaded emd save it in the lOP. We can then 
save time, trouble and lOP space by reading the ZSDOS 
clock directly through the clock driver. This sneaky tech- 
nique also allows the lOP clock to continue working even if 
another DOS is later loaded, as long as the dock driver 
remains undistuibed. 

lOP Clock Operation 

CLKIOP {Listing 1), the lOP clock module, works by in- 
tercepting BIOS CONIN requests at ICONIN. We need to 
minimize the time we spend reading the clock and updating 
the clock display to avoid getting in the way of foreground 
application programs, so our first act is to check the console 
status to see if the BIOS already has a character waiting. If it 
does, we get it and return with it immediately. Only if there 
is no character waiting do we pause to read the clock and 
update the deck display. This allows the lOP clock to run in 
the background and take second place to applications utili- 
ties being run in the foreground. 

Each time we update the clock display, we save a copy of 
the updated date/ time buffer to help us minimize the time 
it takes us to update the display. We compare each newly- 
read date/ time byte with the previously updated date/ time 
byte as we step through the process of translating the BCD 
date and time bytes we read from the dock to the ASCII 
bytes we need in the clock display string buffer. Since sec- 
onds change most often, we can shorten the translation 
process by starting with seconds and working backwards 
toward years. As soon as we find an unchanged byte, we 
know the update is complete. 

When we've completed updating our clock display 
buffer, we send the terminal control string to the terminal, 
which will direct it to place the following message in the 
message display field. Then we send the number of space 
characters required to position the clock display where we 
want it in the field, the clock display string, and the special 
message field termination character. Finally, we return to 
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call 
jr 


check ; 
a, display ; 


Update if changed month 
Quit if no change 


i 


Id 

call 


de.dyr ; 
check ; 

; 


Point to display buffer year 
Update if changed year, 
else fall thru 


r 

; Update tezmlnal clock display 


display lid 

call 


hi, tens ; 

; 

pstr ; 


Point to terminal message 
line prefix 
Send it 


r 


Id 
or 


a,(apace8) 

a 
z,clkdisp 


• Number of spaces required 
; before clock display 
; No spaces required 


i 


Id 
Id 


b,a ; 
a,' ' 


Set counter 


1 

•pip: 


call 
djnz 


cout ; 
splp 


Display spaces 


clkdiap 


lid 
call 


hl.dmo 
pstr ; 


Point to clock buffer 
Display it 


J 


Id 


a,(teniiend) 


; Fall thru to send character 


• Subroutine! 


I 




; 

; Display character in A on 


console 


COUti 


push 

push 

Id 

call 

pop 

pop 

ret 


hi ; 

be 

c,a ; 

conout ; 

be 

hi 


Save us from the BIOS — 

BIOS wants character in C 
Display it 


' 1 

; Display 0-texmlnated string pointed to by KL 1 


pstr: 


Id 
inc 
or 
ret 


a, (hi) ; 
hi ; 
a ; 
z ; 


Get character 
Point to next 
Done? 
Yes, quit 


/ 


call 
jr 


cout ; 
pstr ; 


Display ch2u:acter 
Do next 


r 

; Call 


(HL) 






jphli 


JP 


(hi) 




; Start 


with 


check for chimged seconds 1 


aecchk: 


Id 
jr 


de,dse ; 
checkO 


Point to display seconds 


; 

; Start with 


check for changed minutes 1 


; 

itinchki 


Id 


de,dmi ; 


Point to display minutes 1 


; 

; Check 


for changed time/date bytes 1 


check: 


dec 
dec 


hi 

be ; 


Point to next old tlmo byte 
Point to next time byte 


cbeckO: 


Id 
cp 
ret 


a,(be) ; 
(hi) ; 

« ; 


Get byte 

Ccnpare and set flags 

Return if no change 


1 


Id 
JP 


(hi), a ; 
na2hc ; 


Else update old buffer byte 
And update display buffer 


J 

; Change of hour, so check 


if hourly alarm is desired 


hour: 


Id 


a, (beep) ; 


Hourly alarm? 



or a 

Id a, bell ; Send beep If so 

call nz , cout 

Format clock display correctly for 12 or 24 hour tiae 



Id 
or 
ret 

Id 
sub 

jr 
jr 

r 

deui 
jr 

mom: add 
jr 

noon: add 
condun: Id 

call 

f 

Id 
cp 
ret 

f 

Id 
Id 
ret 



a, (time) ; Get time flag 

a 

z ; 24hr, so we're done 



a,(hr) 
12h 
z,noon 
c,mom 



condun 



; Get bed hour 

; Noon 
; Morning 

; Decimal adjust time to bed 



a,12h 

nz, condun ; Not Midnight 



a,12h 

de,dhr 

ma2hc 

a,(dhr) 
■0' 

nz 



(dhr),a 



; Convert display to 12hr 

; Check for leading 

; No, we're done 

; Replace leading with a space 



Device Select Routine 

Entry: B=OFFH - Remove lOP 

Exit : A»0, Z if bad coamaiui, AOO, NZ if ok 



select: inc 
jr 



b 

z, remove 



Turn clock off 



; Any lOP functions not in^deraented return ZERO to the 

caller. 

& ; Any call here returns Z 



hi, cons ; Our input jump table 
de, const ; Our output jump table 
b,7 ; Patch 7 jus^s 



zero: 


xor 




ret 


; Remove lOP 


remove: 


Id 




Id 




Id 



Replace jump target at Hlrt-l with DE, 
increment HL and DE by 3. 



target: inc 


hi 


Id 


(hl),e 


inc 


hi 


Id 


(hl),d 


inc 


hi 


inc 


de 


inc 


de 


inc 


de 


djnz 


target 


nzero: or 


Offh 


ret 





Point to our jump target 

Move low order 

Point to high order 

Move it 

Point to next lOP input junp 

Point to next lOP output juiq> 



; Iio<^ to do next 

; Any call here returns NZ 



lOPINIT is one-time initialization code that is always 
called by the lOF loader when the lOP is first loaded and 
never ageiin. The space used by lOPINIT can be reused as 
buffer space if required. 

The seven character 10 jun^s in the NZBIOS jump table are 
vectored to our lOP Input Jump Table. The NZBI06 has a 
jump table similar to our lOP Output Jump Table whose 
targets go directly to the BIOS character 10 routines . The 
address of this table is maintained at NZBIOS-t-1 . The lOP 
is 'installed' by pointing the jumps in our lOP Output 
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ICONIN to check the BIOS for another character and if none 
is waiting, we continue to loop, reading and updating the 
clock display in our spare time, until a character is returned 
by the BIOS. We then return to the calling program with the 
character that was originally requested. 

Loading the lOP Clock Module 
You can customize CLKIOP's configuration buffer, in- 
cluding the terminal control string and the address for the 
ZSDOS clock driver, assemble the completed lOP clock mod- 
ule to a REL file and load it into the lOP buffer with NZCOM 
or JETLDR. It is just over 400 bytes long and fits nicely into a 
'standard' 12 record (1.5k) NZIOP buffer with plenty of el- 
bow room left over for future 'enhancements'. 

Next time, however, we'll look at lOPLDR, a small gen- 
eral-purpose lOP loader REL module that does most of the 
standard work that it takes to load, control and remove an 
lOP module. We'll see how lOPLDR and a few routines spe- 
cific to the lOP clock module can be combined to create 



Jump Table to the NZBIOS table. If no lOP action Is to 
take place, our lOP Input Jump Table vectors directly 
through the lOP Output Jtimp Table to the NZBIOS jump table . 



iopinltxld 
or 



Id 
Id 

Id 

Id 
Id 
Id 
Id 



a, (seconds) ; Include seconds? 

a 

nz,init ; Yes 



; Patch display to end 
; with minutes 



( colon ) , a 
hl,minchic 



; Patch ad<3x of change 
; checking routine 
(chktij»fl),hl 

a,0c3h ; Don't recheck minutes 

(updatm) ,a 

hl,updath ; Skip to checking hours 

(updatiftfl),hl 



Initialize lOP output jump table 



initi Id 
dec 
Id 
dec 
Id 
Id 



Id 
jr 

Clock buffers 



hl,(l) 

hi 

cl,(hl) 

hi 

a, (hi) 

hi , const 

b,7 
teurget 



yr: 
bo: 
da: 
hr: 
mi: 



db 
db 
db 
db 
db 
db 



; BIOS+3 

; BI0S-f2 

; BlOS-fl 

; BIOS table 

; Our lOP output jun^ table 

; Seven jumps 



Year 

Month 

Day 

Hour 

Minute 

Second 



Copy of clock buffer after last display update. Fill 
character must be non-bed character to ensure ccmplete 
display conversion at startup. 



Last updated year 
Month 
Day 
Hour 
Minute 
Second 



oyri 


db 


on 


can: 


db 


on 


oda: 


db 


on 


ohrt 


db 


on 


oni! 


db 


on 


ose: 


db 
and 


on 



; End of CLKIOP.Z80 



I0PCLK.COM, a stand-alone utility to install and remove the 
lOP clock display module. lOPCLK also allows you to use 
ZCNFG to coi\figure the operation of the final lOP clock 
module. 

Removing the IOPCU< lOP Module 
An lOP module can be removed by simply loading 
another lOP module over top of it. Alternatively, 
I0PCLK.COM (when we have created it!) will be able to 
'remove' the clock lOP module when the 'R' option is 
selected by calling the lOP SELECT routine with B=OFFh, 
causing the SELECT routine to restore the original lOP input 
jump table so that all jumps point directly to the output jump 
table. This produces a 'dummy' lOP module that simply 
passes on all BIOS calls without interception and effectively 
deselects the lOP. 

interaction With Applications Programs 

Application programs usually get input characters from 
the user in one of two ways. When programs want to quickly 
check to see if the user has entered a character and continue 
with their work if nothing is waiting, they call the BIOS 
CONST routine. If no character is waiting, the program can 
then continue merrily on its way. If there is a waiting charac- 
ter, it can be retrieved by calling the BIOS CONIN routine. 
The SYSLIB character input routine CONDIN provides a 
simple method of doing this, returning immediately if no 
character is waiting and retunung with the character if one 
has been entered. 

The lOP clock works best with foreground applications 
utilities that get characters from the BIOS using BIOS CONIN 
requests. This method is typically used when a program can 
sit and wait until a character has been entered. The SYSLIB 
character input routine CIN works this way, waiting until a 
character has been entered and then returning with it. Most 
interactive utilities, including WordStar, ZPATCH, ZP, ZDB, 
IMP, SCAN24, et cetera, use CONIN calls for most character 
input. The lOP clock display is constantly updated in the 
background when these programs are operating. 

Instead of calling CONIN and waiting for a character to 
be returned, however, some utilities try to do the job of the 
BIOS themselves, continually calling CONST until a charac- 
ter is detected and only requesting the character from 
CONIN after they already know that a character has been 
entered. On a call to CONIN, the lOP clock module sees that 
a character is waiting and won't stop to update the lOP clock 
display. As a result, the lOP clock module can't read the 
clock and update its display during operation of programs 
that get their character input this way. Some examples are 
dBase-II, ZDE, QL, XOX, VIEW and VTYPE. 

Other utilities, including assemblers, linkers, and copy 
and directory utilities, don't check for console input at all for 
long periods of time. The lOP clock display will not be 
updated when console input is not being requested. The 
display will be updated again, however, at the next console 
input request when there is no character already waiting. 

Why then, you might ask, don't we just make life easier 
by intercepting CONST calls to read the clock and update the 
lOP clock display? The reason is that CONST is called much 
more often than CONIN and it just slows things down too 
much to read the clock that often. Or at least my Ampro 
BIOS clock, which is pretty fast. Reading the clock during 
each CONST call drastically reduces the apparent terminal 
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Boyer-Moore String Search Algorithm 
By Terry Hazen 



Bridger Mitchell's last Advanced CP/M column {TCJ 45) 
described a Z80 implementation of the Boyer-Moore string 
search algorithm. He illustrated the traditional method of 
creating a displacement table to determine the skip values 
required during the search process. However, there is a 
simpler and faster way. Since at each node we try to match 
the pattern to the text starting with the rightmost pattern 
character and working from right to left, we can derive each 
skip value as a by-product of the search process itself. 

For example, if we load A with the text character we are 
searching for in the pattern, HL with the pointer to the end 
of the pattern and BC with the length of the pattern, we can 
search the pattern from right to left with the Z80 instruction 
CPDR. If CPDR returns a NZ flag, we have no match and 
must use a skip value equal to the length of the pattern. If 
we have a match, BC returns with an offset from the begin- 
ning, or left character, of the pattern to the match position. 
The skip value for the next match attempt is simply the 
of&et of the match position from the right end of the pat- 
tern, or 

■kip ■ p«ttam_length - BC - 1 

Using one of Bridget's examples: 



1234567890 
Tsxti avarywhare 

Pattaxn: w h a r a 



Here, A would contain 'h', HL would point to the right 
hand 'e' in the pattern 'where', and BC would contain 5, the 
length of the pattern. The CPDR instruction will quit when 
it matches the 'h' in 'where' and return BC=1. The next skip 
value would then be 5-1-1=3: 



1234567890 

T»xt! avarywhera 

Pattami w h a r a | 

-->whara 



; Sllda pattern right 3 bytaa 



While the use of the CPDR instruction illustrates how the 
search process itself can generate the skip value for the next 
match attempt, its actual usefulness in matching real text 
characters in the pattern is limited, as you are limited to 
exact case matches. More flexible 'discrete' code that allows 
you to match characters ignoring case and allowing wild- 
card pattern characters is more complicated and slightly 
slower, but does the same job. • 



baud rate and slows down screen display updates dramati- 
cally and imacceptably. 

Bells and Whistles 

To avoid obscuring the main points, 1 didn't discuss all of 
the features you will find in the CLKIOP clock display code. 
For example, you can use configure the lOP clock module to 
sound an hourly alarm. It can also be configured to display 
time as his:mins with the display updated every minute, or 
as hrsaninsrsecs with its display updated every second and 
can be set fcMr 12 or 24 hour time display. 

You can find the full source and documentation for 
CLKIOP and the lOP clock display utility, I0PCLK.COM, in 
lOPCLKlO.LBR tMi your favorite Z-Node. I hope lOPCLK 
helps illustrate another way in which an lOP can be used 
even if you om't use the lOP clock display because you don't 
have a clock, your terminal doesn't have a host terminal mes- 
sage field or you use a different BDOS. Maybe you have 
some ideas of your own for new lOFs. 

Next time we'll look at lOPLDR and use it to create the 
stand-alone lOP clock display utility I0PCLK.COM. • 



MOVING? 



Don't leave us behind! 



Send Change of Address six weeks prior to move. 



Promotional 

and 

Technical Writing 

for Electronics Marl<eting 

***** 

Technical Articles for Publication 

Advertising Concepts and Copy 

Product and Service Brochures 

Press Releases 

Speeches and Lectures 

Editing/Rewrite Service 

Consulting 

***** 

Bruce IVIorgen 

P.O. Box 2781 

Warminster, PA 1 8974 

215-443-9031 

(Voice, Data by Appointment) 
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Servos and the F68HC11 



By Matt Mercaldo 



The servo is a wonderful device that can be used for mo- 
tion control. These small units have high turning torque as 
well as high holding torque, A limitation of servos is that 
most do not turn a full three hundred and sixty de- 
grees. In most small robotic applications this is not a 
factor. The following code and article will describe 
how to turn a servo. The servo used is a Futaba S9601. 
I have to tharJc the manager of a little hobby shop 
nearby for the donation of this unit from his "junk 
box". 



wave. The timer interrupt service routine is -SERVO. 
NEXTSERVO is a pointer to a piece of code that knows 
what part of the wave to build next. There are only two parts 



Onward 

Servos work in a curious manner in that a control 
signal determines what position should be taken next. 
This signal is a regular sixteen millisecond wave 
whose duty cycle determines the servo's position. The 
position is determined from a one to two millisecond 
window or duty cycle. Listing 1 is the code for the 
servo. The constant BIAS is an offset from the start of 
the sixteen millisecond wave cycle. The constant STEP 
tells how many system E clock ticks for a "step". 

The wave in figure 1 is what the signal looks like to 
run a servo. From point 1. to point 4. is sixteen milli- 
seconds. Point 1. to point 2. is the BIAS. Point 2. to 
point 3. is the window of movement. In the following 
code, this section ( point 2 to point 3) is divided into 
256 steps. 



A look at the Code 
The timers in a 68HC11 are based on the two 
megahertz E clock. A full 65535 ticks is 32 millisec- 
onds. 32720 ticks are roughly half of that and consti- 
tute a 16 millisecond FRAME in the code. The wave 
table is generated by MAKE_STEP_TABLE. The table 
has 256 elements. Each element is composed of two, 
sixteen bit numbers. The first number is a count of 
how many ticks of the E clock make up the high part 
of the wave while the second number is a count of 
how many ticks of the E clock make up the low part of the 



( Prlmltlva Servo Controller ) 

( By Matthew Mercaldo ) 

( 41 South Park Street ) 

( Oconcmouoc, Wlaconaln 53066 ) 



( Servo used !■ the FUTABA S9601 mini servo ) 

( This module will establish 256 locations for the 

( revolution of the servo ) 

( Down Load the Startup code and 68HC11 asseinbler before ) 

( downloading this module ) 

HEX 

BOOO CONSXANT PORTA 

DECIMAL 

OCIF COHSTAHT SIGHAL_BIT ( PORT A bit 7 is the signal bit ) 
( connect the white lead of the servo to PORTA bit 7, the 
( black lead to ground and the red lead to S volts ) 



768 CONSTANT BIAS 



15 CONSTANT STEP 

I PS ( ps — count ) 
I FRAME ( - count ) 
s MAKE STEP TABLE ( 



( Bias la the amount of tine ) 
( required to not make the servo ) 
( chatter at the lew positions. ) 
( There will be 13 system B clock) 



( ticks per "step" of servo. 
STEP * BIAS + ; 
32720 ; ( 16 milliseconds ) 
; compiles table into the dictionary 

; the table is lebit UP | 16bit DOWN 

; for 256 count 



> 



256 DO I PS 



FRAME I PS 



LOOP 



( create the wave/ position table ) 
CREATE POSITION TABLE MAKE STEP TRELE 



VARIABLE NEXT_SERVO ( 
( 



A vector which points to the next ) 
routine to fire ) 



VARIABLE POSITION 
VARIABLE -*SERVO_UP 

VARIABLE -'SERVO DN 



( offset to the wavefom pair ) 

( used for defered access to the up and ) 

( dcwn routines ) 



to the wave that 



Matthew Mercaldo is employed by a huge firm. With a small group, he develops 
software tools for field service engineers to do their thing. At 4:30 or 5:00 p.m., 
when the whistle blows, his thoughts race toward the edge. He dreams of articulated 
six legged xvalking beasts, electronic brains that can fend for themselves, and the 
stuff of "U.S. Robots and Mechanical Men. ' Someday he dreams of running power 
out to his garage, and with his wife and a select group of friends, opening his own 
automaton shop - and thus partially fulfilling his childhood dreams. (Plutonium, 
Tritium and the like are still not available for public 'consumption'; but seeing the 
moons of Jupiter would be spectacular in one's awn starcruiser!) 



can be built; the up part and the down part. 
-SERVOUP sets the signal line bit 
high then gets the appropriate count 
from a combination of the position 
table and the POSITION offset into the 
table, and finally sets the 
NEXT_SERVO vector to point to 
-SERVGDN. The only difference be- 
tween ~SERVO_UP and ~SERVO_DN 
is that -SERVOUP accesses the up 
part of the wave table element and sets 



The Computer Journal / #52 



31 



COIS BI ( - ;anable all Intarrupta ) 



CLi NEXT " me 

BMD-CODB 

COIS DI ( — ;cllMble all interrupts ) 
ASSEMBLER 

SBI NEXT ' JMP 
END-CODE 

CREKCE -SERVO ( — ; Sarvo Interrupt routine ) 

ASSEHBIiBR 

OCIF # A IDH TFLGl ' A STA ( Ackncwledge Interrupt ) 

NEXT_SERVO ' ICX ,X JMP ( execute appropriate ) 

( routine ) 

CBStOB -SERVOJJP ( - ; nakes bit 90 high at apprc^riate tine) 

ASSBffiUR 

PORXA 8I(aaL_BIT ON ( toggle bit on ) 

POemON " U» POSITIOH_XABLE # ADDD XGDX 

( set timwr for ) 

,X LDD TCHT ' ADDD TOCl " STD ( next tine ) 

-*SBKVO_DN * U>X HEXT_SBRVO " STX ( Bet vector for) 

( next time ) 
RII 

-SBRVO_UP -*SERVO_UP 1 

CREATE -SERVO_EW ( — ; makes bit go low at appropriate time) 
ASSEMBLER 

PORTA SIGNAL_BIT OFF ( toggle bit off ) 

POSITION " Ii>D POSITIOH_TABLE # ADDD XGDX 

2 ,X LDD TCNT ' ADDD TOCl " STD 

-»SERVO_UP * U)X NEXT_SERVO " STX 

RTI 

-SERVO DN -^SERVO DN 1 



: P06ITI0N_SEI ( n - ; set position to be an offset Into ) 

( the wave table ) 
DUP 255 > IF E»OP 255 THEN 
4 * POSITION I 

I 

HEX 

J SERVO_INIT ( - ;set servo timer up ) 
00 PORTA CI ( ocl pin starts lew ) 
80 B02£ CI 
00 B020 CI 
-SERVO >T0C1 VECTOR 
-SERVO_0P HEXT_SERVO I 
POSITION SET 



t SERVO_START ( p - ) 
DI 

SERVO_INIT 

IMSK1~C( OCIF OR TMSKl CI 
EI 



Figure 1 
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the signal bit high while ~SERVO_DN accesses the down 
part of the wave table element and sets the signal bit 
low. Together ~SERVO_UP and -SERVO_DN create the 
servo control signal. The POSITION is set with the word 
POSITION_SET. Since each element in the table is four 
bytes long, the entered number is multiplied by four. 
The reason why each element in the wave table is four 
bytes long is because the 68HC11 counters are sixteen 
bits or two bytes, and there are two of them. 
SERVOSTART turns off interrupts, initializes the timers 
and port A for its use as the signal port. Port A bit 7 is 
the signal output line. The servo will go to position 
once activated. To move the servo first type 
SERVOSTART <CR> to initialize the servo timers as de- 
scribed above, then use the POSITIONSET command 
by typing (for example) 50 POSITION_SET <CR>. 

Servos are a tight, compact, powerful little actuators. 
In future articles we will use them to build wondrous 
robotic toys. I hope you have as much fun experiment- 
ing with servos as I did in researching this article. Once 
again have fun with Forth!© 



fr 



^ 



Do You Have 
Something To Tell? 



^ 



What have you been cooking up on 
your project bench? 

Want to talk about it? 

TCJ welcomes articles on hardware 

interfacing, control applications and 

other "real-world* projects! 

TC J ^^^ Computer Journal 

PO Box 12, S. Plainfield 
New Jersey 07080-0012 



J 



Baseball provides an escape. Furthermore, there is no other place in society that I know of which the 
perimeter of play and the rules are clearly defined and known to everyone — in which justice is absolutely 
equal and sure. Three strikes, you're out. I don't care if you hire Edward Bennet Williams to defend you; 
three strikes, you're still out. Baseball is an island of stability on an unstable world. 

—Bill Veeck 
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Z-System Corner 



Programming for Compatibility: Z-System and CP/I\/I 

By Jay Sage 



As noted in the sidebar to my columns, I serve as the Z- 
System sysop on GEnie. My principal duty is to conduct a 
Real Time Conference (RTC) at 10 pm Eastern time on the 
first Wednesday of each month. These sessions are group 
chats, and they give GEnie callers a chance to ask questions 
and make comments. When I accepted this position with 
GEnie, I had expected that many Z-System enthusiasts would 
take advantage of the opportunity to discuss Z-System issues 
with me, but it has not turned out that way. Relatively few 
people show up for these sessions. 

They have not been without value, however, and one of 
the most valuable took place this past June. David 
Goodenough, the author of QTERM (the program for Z80 
computers that is currently the number-one subject of 
interest), was in attendance as usual, and he and I got into a 
discussion about the lack of sharing and commonality 
between the Z-System community and the community of 
vanilla CP/M users. 

The Issue of Compatibility 

The discussion started when I mentioned that we were 
begirming work on a replacement for BYE. David asked if it 
would work under CP/M, and I replied that it would abso- 
lutely require a Z-System. David found this very annoying 
and complained about the way the Z commuiuty ignores the 
large pcut of the 8-bit computing world that, for whatever 
reason, sticks with standard CP/M. 

In the case of BYE, I do not accept David's criticism. The 
main motivation for writing a new version of BYE is that 
many of the functions and a large part of the code in BYE is 
completely unnecessary on a Z-System. For example, Z-Sys- 
tems are inherently secure emd do not need BYE to provide 



Jay Sage has been an avid ZCPR proponent since the very first version appeared. 
He is best known as the author of the latest versions 3.3 and 3.4 of the ZCPR com- 
mand processor, his ARUNZ alias processor and ZFILER, a "point-and-shoot" shell. 

When Echelon announced its plan to set up a network of remote access computer 
systems to support ZCPR3, Jay volunteered immediately. He has been running Z- 
Node if 3 for more than five years and can be reached there electronically at 617-965- 
7259 (MABOS on PC Pursuit, 8796 on Starlink, pw^DDT). He can also be reached 
by voice at 617-965-3552 (between 11 p.m. and midnight is a good time to find him 
at home) or by mail at 1435 Centre Street, Newton Centre, MA 02159. Jay is now 
the Z-System sysop for the GEnie CP/M Roundtable and can be contacted as 
JAY.SAGE via GEnie mail, or chatted with live at the Wednesday real-time confer- 
ences (10 p.m. Eastern time). 

In rod life. Jay is a physicist at MIT, where is tries to invent devices and circuits 
that use analog computation to solve problems in signal, image and information 
processing. His recent interests include artificial neural networks and supercon- 
ducting declronics. He can be reached at work via Internet as SAGE@LL.M1T.EDU. 



security. Furthermore, the externally accessible multiple 
command line makes it possible for BYE to have the operat- 
ing system perform functions that are currently included in 
the BYE code. 

A BYE for Z-Systems could be sigruficantly smaller and 
more flexible than a BYE for CP/M, and we would not want 
to carry the overhead demanded by CP/M. David's response 
to that was to question, then, why he should carry any over- 
head for Z-System in the programs he writes (since he never 
uses any form of Z-System). 

I thiiJc the difference is that BYE is a piece of resident 

Compatibility, like motherhood, is almost 
good by definition! 

code, something that becomes part of the operating system of 
the computer. As such, it is much more important for the 
code to be as short as possible. In an application or utility 
program, however, the importance of keeping code short is 
much less, and the importance of compatibility and wide- 
ranging applicability is much greater. With respect to those 
kinds of programs I think that David is absolutely right, and 
we should be making a greater effort at compatibility. That is 
the issue I will address here. 

Why Should We Want Compatibility? 

Compatibility, like motherhood, is almost good by defini- 
tion! Obviously, a great deal of creative effort is going into Z- 
System development, and it is best if the fruits of that effort 
can be shared by the largest number of people. But there are 
also some very specific reasons why we in the Z community 
should be interested in compatibility 
with CP/M. 

One reason that affects Z users di- 
rectly is that with NZCOM and 
Z3PLUS we are not locked into Z-Sys- 
tem, and we are much more likely to 
drop back to CP/M to perform some 
tasks. Sometimes we are going to use 
an application that is a real memory 
hog. At other times we have to use a 
program that cannot operate under Z- 
System, such as Uniform (for working 
with foreign-format diskettes). Uru- 
form works by introducing patches di- 
rectly into the operating system code, 
and it will work, therefore, only when 
the machine is rurming the exact ver- 
sion of CP/M for which it was written. 
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(I have made perfunctory attempts at finding a way to adapt 
Uniform to NZCOM, but so far I have not succeeded.) It 
would be very convenient if our familiar Z-System tools 
would still work after we dropped back to CP/M. And we 
certainly don't want them causing a system crash if we in- 
voke them by accident under CP/M. 

A second advantage, and one that David Goodenough 
raised to encourage me to pursue greater compatibility, is 
that people still using vanilla CP/M would get a taste of 
what Z-System can offer. Under CP/M, Z-System tools 
would require an onerous patching process. If more CP/M 



Listing 1. 

Source code for the teat program that 

Incorporatea an Internal EHV/TCAP for when the program 

!■ run under atandard CP/M. 



; PROGRAM: 
; AUTUCA: 
; DATE: 



ZTEST.zeO 
Jay Sage 
June 16, 1991 



; Thia la a program to teat the technique of including 
; an internal EHV and TCAP. 



»-— Bxtemal Referencea 
maclib cpmenv.lib 
.requeat vlib.ayalibO 



extm 
extm 



z3vinit,cla,at ; VLIB routinea 
vprint 



Standard Z-Syatem program header 



; To make the code iroric tranaparently with CP/M, the 

header 

; la inltializecl to point to the internal ENV. Vfhen the 

; program ia run under ZCPR33 or later, the addresa of the 

; external Z-Syatem BNV will be poked Into the code by the 

; ccnmand proceaaor at run time. 



jp 


atart 




db 


'Z3ENV' 


; Signature 


db 


1 


; EUV type 



envptr: : 

dw intonv ; Pointer to ENV 

; Material for uae with ZCNFG can be included here. 

; --—-—— Internal ENV and TCAP placed here 

intenv: cpmenv ; Use macro 

; Actual Program Code 

atart: 

Id hi, (envptr) ; Initialize 
call z3vinit 

; clear screen 

; Position curaor 

; Diaplay a meaaage 

; Highlighting on 

; Highlighting off 

; Put curaor at bottom 



call 


els 


call 


at 


db 


10,10 


call 


vprint 


db 


'This ia ' 


db 


1 


db 


'highlighted' 


db 


2 


db 


' video 1' 


db 





call 


at 


db 


22,1 


ret 




end 





Listing 2. 

This la macro code that defines an ENV and 
TCAP for a CP/M system. 



; PROGRAM: 
; AUTHOR: 
; DATE: 



CPMENV.LIB 
Jay Sage 

June 16, 1991 



; System configuration information (•*•♦• USER EDIT ♦*••*) 

cpumhz equ 4 ; CPU speed in MHz 

; Operating system addresses and sizes. 

blospg equ Odlh ; Page where BIOS ataxta 

bios equ lOOh * blospg 

doss equ 28 ; Size of DOS In records 

dos equ bloa - 80h * doss 

ccps equ 16 ; Size of CCP in records 

ccp equ doa - SOh * ccpa 

; Information about drives and user areaa available 

; PONMLKJIHGFEDCBA 

drvec equ OOOOOOOOOOOOllllB 

hlghdak equ 'D' ; Latter of higheat drive 

maxdisk equ highdak - '(' ; Higheat drive (A>*1) 

maxuaer equ 31 ; Higheat uaer area 

; Data about conaole acreen and printera 



; Width of CRT acreen 

; Number of linea on 

; Number of linea to uae 

; Printer width 

; Printer total length 

; Printer linea to use 

; Formfeed flag (1 if 



; Here is a macro to define and internal ENV for uae 
; under CP/M. 



crtwid 


equ 


80 


crtlen 


equ 


24 


acreen 






crtuse 


equ 


crtlen -2 


prtwid 


equ 


80 


prtlen 


equ 


6£ 


prtuae 


equ 


prtlen - 8 


prtff 


equ 


1 


used) 







cpmenv macro 






jp 





; Dummy jump address 


db 


'Z3ENV' 


; Environment ID 


db 


81h 


; ENV type 


dw 





; external path 


db 





; elements in path 


dw 





; RCF address 


db 





; number of recorda in RCP 



; LOTS MORE OMITTED 



dw 
db 



intenv ; ZCPR3 Environment Deacriptor 
2 ; number of recorda in ENV 



; LOTS MORE ZERO VALUES 

db cpumhz ; Proceaaor Speed in MHz 

db maxdisk ; maximum disk 
db maxuaer ; maximum uaer 



db 
db 
db 



; 1=0K to accept DU, O»not OK 



1 

0,0 

crtwid ; width of CRT 
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useis realized the kinds of programs that would become 
available to them directly, with no need for patching, they 
would be more likely to upgrade to Z-System. 

What Does Compatibility Demand? 

What do we mean when we talk about Z-System pro- 
grams being compatible with CP/M, and what coding re- 
quirements would such compatibility impose? 

As Bridger Mitchell pointed out long ago in his Advanced 
CP/M column that used to appear in TCJ (and which we all 
hope will reappear in the future [Ed.: I second that!] ), all 
programs should examine the environment in which they 

All programs should examine the environment 

in which they have been called on to operate. 

Then, they must either adapt properly to the 

environment or terminate gracefully. 

have been called on to operate. Then, they must either adapt 
properly to the environment or terminate gracefully with an 
appropriate message. 

Two basic things that programs might have to determine 
before they attempt to perform their function are: (1) the kind 
of CPU— 8080/8085, Z80, 64180, Z280; and (2) the kind of op- 
erating system— CP/M-2.2, CP/M-Plus, Z-System. In the 
case of a Z-System, it might be further necessary to deter- 
mine the version of ZCPR3 (3.0, 3.3, 3.4) and the type of 
implementation (manual, NZCOM, Z3PLUS). 

The Z-System is a far more varied object than CP/M, and 
one's determination of the environment has only begun 
when a Z-System has been detected. The simplest form of Z- 
System, I suppose, would have only one module: the ENV 
descriptor. The other modules and facilities in Z-System's 
long list are, I believe, all optional: named directory register 
(NDR), multiple command line, shell stack, flow control 
paclcage (FCP), message buffer, command search path, and 
soon. 

Because of the range of Z-System implementations that 
are possible, it is already incumbent on Z programs to make 
sure that the facilities they expect or depend on are, in fact, 
available. Most of the routines in the assembly language pro- 
gramming libraries used to write Z programs (i.e., VLIB, 
Z3LIB, and SYSLIB) already return error codes when the fa- 
cility requested is not available. All Z programs should check 
these return codes and proceed in appropriate ways when 
things don't work out as intended. 

What should be expect from Z programs when they are 
run under CP/M? At the very least, as I mentioned earlier, Z 
programs should absolutely be safe under CP/M. We might 
settle for a simple return to the CP/M command prompt, but 
ideally, programs should report that they could not run and 
why. It is quite unnerving to invoke a program and just get 
the command prompt back. 

A higher level of compatibility would be for the Z pro- 
gram to perform those of its functions that make sense under 
CP/M. When runiung under Z-System the program might 
recognize named directories and return information in Z-Sys- 
tem message buffer registers; under CP/M, only DU: direc- 
tory references could be handled, and information that 
would normally be recorded in the message buffer would be 
discarded. 

The highest level of compatibility, which we will explore 
in more detail later, is to have the program perform its full 



range of operations under CP/M by including an internal 
ENV module (including the TCAP component, which tells 
how to operate the console terminal). In this way, the pro- 
gram would thiiJc it was rurming under Z-System even when 
actually running under CP/M. 

I have not had time to think through all these issues fully, 
and my views may be refined with further thought and input 
from others. At the moment, I can see only one fundamental 
difference between a minimum capability Z-System and a 
CP/M system. That is the difference in command processors, 
and specifically the more sophisticated parsing of the com- 
mand line that ZCPR3 performs. 

The first two tokens on the command line are treated as 
file references, and the default file control blocks (FCBs) at 
5CH and 6CH are filled in with information about those two 
files. With ZCPR3, directory references of the form DU: and, 
if named directories are implemented, DIR: are recognized. 
Besides placing the proper drive letter into the FCB, the user 
number for the file is placed into a special location. 

Under CP/M, these operations will not take place, and an 
internal ENV will not help. In fact, the internal ENV, which 
will make the program think that it is running under Z-Sys- 
tem, could cause problems. To make programs that rely on 
the default FCB data work, we would have to add significant 
additional code to the program. First, we would have to de- 
tect the use of the internal ENV (this would be easy), and 
then we would have to provide alternative code for manually 

What should be expect from Z programs 

when they are run under CP/M? At the very 

least, they should absolutely be safe. 

parsing the filename tokens into the FCBs. While this might 
represent a significant extra burden in the code, I would rec- 
ommend that we do this in the future for those programs 
that can afford the extra code and whose functionality is not 
already available in a standard CP/M program. 

Where Does Compatibility Stand Now? 

David Goodenough was under the impression Z-System 
programmers totally ignore CP/M and that nearly all Z-Sys- 
tem programs will not work under CP/M. This impression is 
not really fair. 

First of all, a great many Z prograims — perhaps even the 
majority — could not possibly run under CP/M because their 
function would make no ser\se under CP/M. Here are a few 
examples: 

(1) PATH or ZPATH: configures the Z-System 
search path for COM files; 

(2) PWD: reports the names and associated drive/ 
users of currently defined named directories; 

(3) SALIAS: full-screen tool for defining stand-alone 
multiple-command-line aliases; 

(4) ZEX: a sophisticated batch processor that feeds 
commands to the multiple command line and uses the 
message buffer for control communication; 

(5) ADIR: displays the names of alias scripts defined 
for the ARUNZ extended command processor; 

(6) LSH: a full-screen history shell and command- 
line editor. 

It was interesting to see what happened when these pro- 
grams were operated under CP/M (which I could do easily 
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db 

db 



dw 

db 



db 



db 
db 



db 



crtlen ; number of lines on CRT 

crtuse ; number of lines of text on CRX 

drvec 


prtwid ; data for printer 

prtlen 

prtuse 

prtff 

0,0,0,0 



dw 


ccp 


db 


ocpe 


dw 


dos 


db 


dosa 



dw 



bios 



db 


'SH 


db 


'VAR 


db 


' 


db 


' 



; shell variable filename 

; shell variable filetype 

; filename 1 

; filetype 1 



; HORE SIMILAR DATA 
Fill unused space with nulls 



rept 

db 

endm 



12e-($-intenv) 




; End of Environment Descriptor - beginning of TCAP 

. ♦•«** USER EDIT ***** 

; Extended Termcap Data 

ESC EftU 27 ; ASCII escape character 

; I have aidapted the convention that a terminal name is 
; terminated with a space character, therefore no spaces 
; within the name. Also that the tentiinal name is unique 
; in the first eight characters. 



HZTCAP: DB 



'WYSE-50D 



; Terminal name (13 bytes) 



; The Graphics section is no longer fixed so we must 

; provide an offset to it. One byte is sufficient for a 

; two-record TCAP. 



DB 



GOEli>-NZTCAP 



; Offset to tX)ELD 



; Bit 7 of B14 indicates the new Extended TCAP. Bits 6-0 
; iure undefined. 



B15 bO 
B15 bl 



lOOOOOOOB 



Standout 



; Extended TCAP 



dim, 1 s inverse 



; B15 b2 


No Wrap 


; BIS ba 


No Scroll 


; B15 b4 


ANSI 


DB 


OOOOOlllB 


DB 


•K'-'C 


DB 


•J'-'C 


DB 


'L'-'«' 


DB 


'H'-'«' 


DB 


00 


DB 


00 


DB 


00 


delay 




; Strings start 


hare. 



Power Up Delay - None, 1 - lO-seo delay 
= Line Wrap, 1 >: No Wrap 
= Scroll, 1 - No Scroll 
= ASCII, 1 = ANSI 



; Cursor up 

; Cursor down 

; Cursor right 

; Cursor left 

; Clear-screen delay 

; Cursor movement delay 

; Cleiur-to-end-of-line 



on my Televideo 803H, which runs NZCOM). ZPATH po- 
litely reported that there was no ZCPR3 path, and PWD an- 
nounced that there was no NDR (named directory register) 
allocated. ZEX gave a more general message indicating that 
the facilities it required for operation were not available. 
These responses were all acceptable and reasonable, and they 
meet the requirements I outlined above. 

ADIR did not do so well. It tried to run and ended up 
accessing a bogus drive, from which I had to recover by 
pressing control-C. S ALIAS, to my surprise, did even worse. 
Although one time it gave me the message "TCAP?", indicat- 
ing that it was checking the TCAP for adequate terminal sup- 
port, all the other times it crashed and locked up the system. 
So did LSH. Obviously, these programs are not checking 
properly that the memory referenced by the embedded ENV 



DB 


ESC, 


' + ',0 


; Clear-screen string 


DB 


ESC, 


'=%+ «+ ' ,0 


; Cursor movement string 


DB 


ESC, 


'T',0 


; Clear-to-end-of-lino 


DB 


ESC, 


')',0 


; Standout-on string 


DB 


ESC, 


'(',0 


; Standout-end string 


DB 







; Terminal init string 


DB 


ESC, 


'(',0 


; Terminal deinit string 



Extensions to Standard 23TCAP 



DB 


ESC, 


'R' 


,0 


; Line Delete 


DB 


ESC, 


'E' 


,0 


; Line Insert 


DB 


ESC, 


'Y' 


,0 


; Clear-to-end-of -screen 



; Set Attribute strings once again included. 



DB 
DB 



ESC,'G',0 
'0248', 



; Set Attributes 
; Attributes 



; These two allow reading the Terminal's screen. 



DB 


ESC,'?' 


,0 


DB 


ESC, '6' 


,0 


; Graphics 


start here. 




GOELDi DB 








; Read current cursor pos 
; Resid line until cursor 



; On/Off Delay 



Graphics strings offset from Delay value. 



DB 


ESC, 'H', 2,0 


; Graphics mode On 


DB 


ESC, 'H', 3,0 


; Graphics mode Off 


DB 


ESC,"0',0 


; Cursor Off 


DB 


ESC,"1',0 


; Cursor On 



; Graphics Characters 



DB 


'2' 


DB 


'3' 


DB 


'1' 


DB 


'5' 


DB 


' ! ' 


DB 


•6' 


DB 


•7' 


DB 


/ • f 
t 


DB 


•0' 


DB 


'.' 


DB 


'8' 


DB 


'9' 


DB 


•4' 



Upper left comer 
Upper right comer 
Lower left comer 
Lower right comer 
Horizontal line 
Vertical line 
Full block 
Hashed block 
Upper Intersect 
Lower Intersect 
Mid intersect 
Right intersect 
Left intersect 



Fill unused space with nulls 



REPT 
DB 

ENDM 



128-($-NZTCAP) 




; End of NZTCAPD 
endm 
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pointer actually contains a Z-System environment (ENV) 
module; they must just be plowing on ahead. 

I tried a lot of other programs of this sort, and in almost 
all cases they failed in an acceptable way. Many gave mes- 
sages; others simply returned to the command prompt with- 
out having done anything (at least nothing apparent, so I 
assume they did not do any harm). 

Not all Z-System programs maiupulate or take specific 
advantage of Z-System facilities; There are many Z programs 
that perform functions that make perfect sense under stan- 
dard CP/M. Some authors have taken great care to ensure 
that their programs will work in both environments. Hal 
Bower's COPY program (derived from MCOPY) that comes 
with the ZSDOS disk-operating-system replacement is a 
good example of this. Here are some other examples of pro- 
grams whose function makes some sense under CP/M: 

(1) FF: FindFile searches all drives and user areas for 
specified file names; 

(2) DIFF: performs a byte-by-byte comparison of 
two files; 

(3) CD: changes the logged drive/user; 

(4) LBREXT: extracts member files from LBR files 
and optionally uncompresses them; 

(5) LPUT: builds a new LBR file from the files 
named on the command line. 

How did these fare under CP/M? Although FF performs 
a function that would be useful under standard CP/M, it is 
coded to make mandatory use of Z-System features, and it 
delivers an error message when one attempts to use it under 
CP/M. 

This is a good example of a program that probably should 
be upgraded to CP/M compatibility. Obviously, FF would 
not recognize or report named directories, and it would have 
to assume that all user areas are available. As for the drives it 



Listings. 

The easentlal material In the patch for 
inatalllng an internal environment into DU35. 



; PROGRAHt 


DU-CPM.Z80 


; AUTHORS 


Jay Sage 


; DUE: 


June 15, 1991 



Tbi* code la a patch that can be used with DU35 to embed 
an internal environment descriptor and TCAP so that DU3S 
can be used under standard CP/M (2.2 or 3) as well as Z- 
-Systaa. To use thia patch, IXJ3S.Z80 mat be assembled as 
usual to a REL file and then linked with the data segment 
(DSBG) Bovad lOOH higher in Bemory to provide a place to 
Insert the ENV. The appropriate linker ccamands with the 
vsrsion-4 libraries are as follcws: 

SLRNK DU35/N,/P:100,/D:2£50,IXI35, 

VLIB/S,Z3LIB/S,SYSLIB0/S,/E 
or 

ZML IXJ35,VLIB/,Z3LIB/,SySLIB0/ D2E50 

This linking leaves the space f rcn 2D50H to 2E4FH free for 
an internal ENV and TCAP, which are defined below in this 
patch. As distributed, this patch is set up with an ENV 
for ay Televideo 803H computer and a TCAP for a Wyse-50 
tezmlnal (this works on the Televideo, too). You should 
edit the file so that it describes your system ( search for 
the sectiona markwl with -•••*• USER EDIT ••••*". 

Once the patch haa bean edited, assemble it to a HEX file 
and then use MLQAD (or MYLOAD> to apply the overlay: 

MliQAO DU>4XI35.COM,DU-CPM.HEX 



should search, it would have to be configured manually, and 
I don't see why ZCNFG, the program that is currently used 
under Z-System to configure it, could not perform this func- 
tion under CP/M, too. 

DIFF, like FF, gives an error message when it is invoked 
under CP/M (in fact, it requires ZCPR33 or later). DIFF 
makes extensive use of Z-System facilities. It determines the 
dimensions of the termirud display, stores certain results of 
the file comparison in Z-System registers, and performs ad- 
vemced error-recovery operations when the program encoun- 
ters certain conditions. DIFF also extracts and compares the 
date stamps for the two files. Thus, although the essential 
function of DIFF would be useful under CP/M, it might be 
difficult to make the code work without those Z facilities. It 
would be worth looking into, I think. 

CD (Change Directory) is primarily intended to log into 
another drive and user area using a named-directory refer- 
ence and to run a special alias when it gets there. Under CP/ 
M it currently appears to do nothing but return to the com- 
mand prompt. It should be made to give an error message. It 
might even be reasonable for it to accept DU: syntax to log 
into the indicated area under CP/M. 

The functions of LBREXT are totally appropriate for CP/ 
M, and there is no reason why it should not work perfectly 
under CP/M. It almost does. The following command works 
fine: 

LBREXT B3:LIBRARy C1:EXTRACT.FIL 

As is perhaps to be expected, it does have problems if one 
tries to use a named directory reference. The one real mistake 
I noticed in the code is that it is coded to determine its own 
name (for use in the help screen) by looking in the Z-System 
external FCB. Under CP/M, garbage appears. Apparently, 
the code does not verify that the system has an external FCB. 



An alternative way to install the TCAP is to extract a 
binary TCAP frcm one of the distribution files (such as 
Z3TCAP.TCP, which is a library collection of TCAPs) 
Then, after installing the DU-CPM patch, use a debugger or 
file editor to install the desired TCAP into DU.COH at 
address 2DD0H (on tc^ of the one installed by this patch) . 



! Syston configuration information (♦♦*** USER EDIT *****) 

; CHITTED MATERIAL SAME AS THE CONFIGURATION 
; EQUATES IN CPMENV.LIB 



intenv equ 02d50h ; Place in DU35 for the internal ENV 



; Install ENV address at beginning of code 

org 109h ; Place for the ENV address 

dw Intenv ; Internal ENV address 



; Install the dummy ENV in the DU35 code 

org Intenv 

; OMITTED MATERIAL SAME AS THE MACRO CODE 
• IN CPMENV.LIB 

; End of NZTCAPD 
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This is a mistake even for operation vinder Z-System. 

LPUT, which also performs a function that is entirely ap- 
propriate for CP/M, misbehaves seriovisly under CP/M. It 
tries to work, but it gets its user areas confused. Since it 
always assumes user for the LBR file, even when one is 
given explicitly in the command, my guess is that it is using 
the default FCB for the first command line token. Second, for 
the list of files to be put into the library, LPUT assumes user 
unless one is given explicitly, in which case it is recognized 
correctly. This suggests that it has not determined properly 
what its logged-in (default) user area is. Small changes in the 
code could probably correct these problems. 

I probably should have clarified one thing earlier in this 

I can imagine why someone would still 

today refuse to use Z-System (it does take 

up some memory), but it is completely 

beyond me as to why anyone would 

continue to use the DRI CP/M-2.2 CCP. 

discussion. 1 have not done these experiments strictly under 
CP/M but rather under ZCPR2, and this may have affected 
the results. A stripped-down 2CPR2 is the most primitive 
system I will consider running. It is a direct, drop-in replace- 
ment for the Digital Research command processor; nothing 
else in the system changes. I can imagine (albeit with some 
difficulty) why someone would still today refuse to use Z- 
System (it does take up some memory), but it is completely 
beyond me as to why anyone would continue to use the DRI 
CP/M-2.2 CCP. 

Compatibility Via an Internal Environment 

I was so intrigued by the possibility of making Z pro- 
grams run under CP/M even when they required full-screen 
terminal capabilities that I could not wait to experiment with 
some real code. Mind you, this is no small thing. I have been 
so busy with other activities that 1 have done virtually no 
code writing for years! My influence on the Z community has 
been only as a mentor. This time 1 just could not wait for 
someone else to perform the experiments. 

As the subject for my first tests, 1 chose the disk utility 
program, DU3. There were two reasor\s for this. First, this is 
a program whose CP/M counterpart lacks some of the most 
useful features of DU3, and 1 have long wished that it would 
work after I dropped down to CP/M. Second, I had just put 
up on my Z-Node a new version, DU34, that Gorm Helt- 
Hansen of Denmark had sent to me, so I knew I had current 
source code to work with. 

There are quite a few possible approaches to patching in 
an internal ENV. 1 am going to start by discussing a little test 
program that I wrote after I had already succeeded with 
DU34 (now DU35). Rather than trying to abstract from the 
DU code, it was easier to write a simple demonstration pro- 
gram. ZTEST, shown in Listing 1, includes only enough func- 
tionality to prove that it works. 

The key idea is to place in the code a two-record module 
contcdning the ENV (i record) and the TCAP (1 record). The 
ENV pointer in the program header is initialized to point to 
this internal enviroiunent. Then, when the program is exe- 
cuted under CP/M, that is the ENV that the program will see 
and use. On the other hand, when the program is run under 
a modem Z-System (ZCPR33 or later), the command proces- 



sor will poke the address of the true (external) Z-System 
ENV into that pwinter, and the program will then see and use 
the real environment. 

The most difficult part of this prqect was writing the 
CPMENV.LIB code. The ENV part was pretty straightfor- 
ward. Almost all the module addresses and lengths are zero! 
The part that took some fime was the TCAP. I finally located 
a good source-code version of the latest TCAP standard and 
was able to import it. A condensed version is shown in List- 
ing 2. 

For patching DU3, 1 took a slightly simpler approach that 
would not have required modifying the source code at all. In 
fact, 1 did make a few changes to correct some errors I no- 
ticed in the version 3.4 code and to make a cosmetic change. 
For one thing, the names of some library routines had mis- 
takenly shorted to six characters, rendering the code unus- 
able with the SLR tools in SLR mode. Using the full iwmes 
should be equally acceptable to M80/L80. 

The most serious error was the inclusion of a large block 
of initialized data near the end of the data segment (DSEG). 
This resulted in a COM file substantially larger than neces- 
sary, since all the uninitialized data now had to be loaded 
into the COM file. I moved that initialized data to the begin- 
ning of the DSEG to join the other initialized data. I called the 
new version DU35. 

Aside from those modifications, which were made for 
other reasons, the patching process actually starts with the 
same assembled REL file as would have been used to gener- 
ate the standard Z-System version of the program. When 1 
linked it with the libraries (VLIB, Z3LIB, and SYSLIB), I made 

A stripped-down ZCPR2 is the most 

primitive system I will consider running. It 

is a direct, drop-in replacement for the 

Digital Research command processor; 

nothing else in the system changes. 

note of where the data segment (DSEG) started. It was at 
2D48H. To make room for an internal ENV from 2D50H to 
2E4FH, I simply relinked the program with the DSEG speci- 
fied as 2E50H. Now all I had to do was to patch in the ENV 
code. 

Initially I did this manually using the command 

GET 100 ;DU35.COM 

to load DU35.COM into memory. Then 1 used a second GET 
command to load an assembled version of the dummy ENV 
and TCAP to the proper address: 

GET 2D50 :CPHENV.COM 

To make sure that the ENV address in this ENV module 
was self-consistent, I poked the correct value in at ENV+IBH: 

POKE 2D6B 50 2D 

Next, I had to poke the ENV address into the pointer at 
109H. The command was: 

POKE 109 50 2D 

Now the memory image had the correct code, and I just 
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BYO Assembler, from page 20 

is the "while" loop in which the condition is tested at the be- 
ginning of the loop, rather than at the end. 

In Forth the accepted syntax for this structure is 

BECIM, evaluate cc MHILE, loop code REPEAT, 

In practice, any code — not just condition evaluations — 
may be inserted between BEGIN, and WHILE,. 

What needs to be assembled is this: WHILE, will as- 
semble a conditional jump, on the inverse of cc, to the code 
following the REPEAT,. (If the condition code cc is satisfied, 
we should "fall through" WHILE, to execute the loop code.) 
REPEAT, will assemble an unconditional jump back to BE- 
GIN. Or, in terms of existing constructs: 



BEGIN, (1) 



cc IF, (2) ... AGAIN, (1) THEN, (2) 



Once again, this can be implemented with existing words, 
by means of a stack manipulation inside WHILE, to re-ar- 
range what jumps are patched by whom: 

: WHII£, ( a cc - a a) IF, SWAP ; 
t REPEAT, ( a a - ) AGAIN, THEN, ; 

Again, nesting is freely permitted. 

The Forth Definition Header 

In most applications, machine code created by a Forth as- 
sembler will be put in a CODE word in the Forth dictionary. 
This requires giving it an identifying text "name," and link- 
ing it into the dictionary list. 

The Forth word CREATE performs these functions for the 
programmer. CREATE will parse a word from the input 
stream, build a new entry in the dictionary with that i\ame, 
and adjust the dictionary pointer to the start of the "defini- 
tion field" for this word. 

Standard Forth uses the word CODE to distinguish the 
start of an assembler definition in the Forth dictionary. In 
addition to performing CREATE, the word CODE may set 
the assembler environment (vocabulary), and may reset vari- 
ables (such as MODE) in the assembler. Some Forths may 
also require a "code address" field; this is set by CREATE in 
some systems, while others expect CODE to do this. 

Special Cases 

1. Resident vs. cross-compilation: Up to now, it has been as- 
sumed that the machine code is to be assembled into the 
dictionary of the machine rurming the assembler. 

For cross-assembly and cross-compilation, code is usually 
assembled for the "target" machine into a different area of 



memory. This area may or may not have its own dictionary 
structure, but it is separate from the "host" machine's 
dictionary. 

The moat comnon and atralghtforward aolution la to provide 
the hoat machine with a aet of Forth operatora to acceaa the 
"target" memory apace. Theae are made deliberately analogous 
to the normal Forth mmory and dictionary operatora, and are 
usually diatlngulahed by the prefix "T". The baalc set of 
operatora required ia: 



TDP 

THERE 

TC, 

TC( 

TCI 

•n 

Tl 



target dictionary pointer DP 
analogouB to HERE, retuma IDP 
target byte append C, 
target byte fetch C( 
target byte (tore CI 
target word fetch ( 
target word store I 



Sometimes, instead of using the "T" prefbc, these words 
will be given identical names but in a different Forth vocabu- 
lary. (The vocabulary structure in Forth allows unambiguous 
use of the same word name in multiple contexts.) The 6809 
assembler in Part 2 assumes this. 

2. Compiling to disb Assembler output can be directed to 
disk, rather than to memory. This, too, can be handled by 
defirung a new set of dictionary, fetch, and store operators. 
They can be distinguished with a different prefix (such as 
"T" again), or put in a distinct vocabulcury. 

Note that the "patching" manipulations used in the single- 
pass control structures require a randomly-accessible output 
medium. This is not a problem with disk, although heavy use 
of control structures may result in some inefficient disk ac- 
cess. 

3. Compiler Security: Some Forth implementations include 
a feature known as "compiler security," which attempts to 
catch mismatches of control structures. For example, the 
structure 



IF, 



cc UNTIL, 



would leave the stack balanced (UNTIL, consumes the ad- 
dress left by IF,), but would result in nonsense code. 

The usual method for checking the match of control struc- 
tures is to require the "leading" control word to leave a code 
value on the stack, and the "trailing" word to check the stack 
for the correct value. For example: 



« 1; 



3; 



IF, 


leaves a 1; 


THEN, 


checks for a 1; 


ELSE, 


checks for a 1 and leaves 


BEGIN, 


leaves a 2; 


UNTIL, 


checka for a 2; 


AGAIN, 


checks for a 2; 


WHILE, 


checks for a 2 and leaves 


REPEAT, 


checks for a 3. 



had to save the file: 

:SAVE 100-2E50 DU.COM 

I presented the procedure above to illustrate how handy 
the Z-System GET, POKE, and transient SAVE.COM pro- 
grams can be when doing this kind of work. (The peek com- 
mand, P, also came in handy to let me see what I was doing.) 
To make the process easier for other people to carry out, I 
then developed a patch program called DU-CPM.Z80. Ex- 
cerpts are shown in Listing 3, where the installation proce- 
dure is described. 



Conclusion 
I hope this column will inspire Z program authors to take 
a careful look at their programs to see how they can be made 
better behaved and more compatible with standard CP/M. I 
hope it will also inspire CP/M programs to think about the 
advantages that Z-System offers to many Z80 computer users 
and to devote the effort required to allow their CP/M pro- 
grams to run effectively under Z-System as well. We will all 
benefit by brining the CP/M and Z-System commimities 
closer together.© 
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This will detect most mismatches. Additional checks may 
be included for the stack imbalance caused by "xmmatched" 
control words. (The 6809 assembler uses both of these error 
checks.) 

The cost of compiler security is the increased complexity 
of the stack manipulations in such words as ELSE, and 
WHILE,. Also, the programmer may wish to alter the order 
in which control structures are resolved, by manually re-ar- 
ranging the stack; compiler security makes this more diffi- 
cult. 

4. Ldbds: Even in the era of structured programming, 
some programmers will insist on labels in their assembler 
code. 

The principal problem with named labels in a Forth as- 
sembler definition is that the labels themselves are Forth 
words. They are compiled into the dictionary— usually at an 
inconveruent point, such as inside the machine code. For ex- 
ample: 

CCXX TEST . . . machine ccxle . . . 
HERE COHSIMtX lABELl 
. . . nachlna code . . . 
lABELl NZ JP, 

will cause the dictionary header for LABELl — text, links, and 
all — ^to be inserted in the middle of CODE. Several solutions 
have been proposed: 

a) define labels only "outside" machine code. Occa- 
sionally useful, but very restricted. 

b) use some predefined storage locations (variables) 
to provide "temporary," or local, labels. 

c) use a separate dictionary space for the labels, e.g., 
as provided by the TRANSIENT scheme [3]. 

d) use a separate dictionary space for the machine 
code. This is common practice for meta-compilation; most 
Forth meta-compilers support labels with little difficulty. 

5. Table DriiKti Assemblers: Most Forth assemblers can 
handle the profusion of addressing modes and instruction 
opcodes by CASE statements and other flow-of-control con- 
structs. These maybe referred to as "procedural" assemblers. 

Some processors, notably the Motorola 68000, have in- 
struction and addressing sets so complex as to render the de- 
dsicxi trees immense. In such cases, a more "table-driven" 
approach may save substantial memory and processor time. 

(I avoid such processors. Table driven assemblers are 
much more complex to write.) 

6. Prefix Assemblers: Sometimes a prefbc assembler is un- 
avoidable. (One example: I recently translated many K of 
Supers assembler code from the Zilog assembler to a Forth 
assembler.) There is a programming "trick" which simulates 
a prefix assembler, while using the assembler techniques de- 
scribed in this article. 

Basically, this trick is to "postpone" execution of the op- 
code word, until after the operands have been evaluated. 
How can the assembler determine when the operands are 
finished? Easy: when the next opcode word is encountered. 

So, every opcode word is modified to a) save its own exe- 
cution address somewhere, and b) execute the "saved" action 
of the previous opcode word. For example: 

... JP opermnd ADD operand* • • • 

JP stores its execution address (and the address of its "in- 
stance" parameters) in a variable somewhere. Then, the oper- 



ands are evaluated. ADD will fetch the information saved by 
JP, and execute the run-fime action of JP. The JP action will 
pick up whatever the operands left on the stack. When the JP 
action returns, ADD will save its own execution address and 
instance parameters, and the process continues. (Of course, 
JP would have executed its previous opcode.) 

This is confusing. Special care must be taken for the first 
and last opcodes in the assembler code. If mode variables are 
used, the problem of properly saving and restoring them be- 
comes nightmarish. I leave this subject as an exercise for the 
advanced student... or for an article of its own. 

Conclusion 

I've touched upon the common techniques used in Forth 
assemblers. Since I believe the second-best way to learn is by 
example, in part 2 I will present the full code for the 6809 
assembler. Studying a working assembler may give you hints 
on writing an assembler of your own. 

The best way to learn is by doing!* 
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TCJ On-Llne 

Readers and authors are invited to join in dis- 
cussions with their peers in any of three on-line 
forums. 

• GEnie Forth Interest Group (page 710) 

• GEnie CP/M Interest Group (page 685) 

• Socrates Z-Node 32 

For access to GEnie, set your modem to hali 
duplex, and call 1-800-638-8369. Upon connec- 
tion, enter HHH. At the U#= prompt, enter 
XTX99486,GENIE and press RETURN. Have a 
credit card or your checking account number 
handy. 

Or call Socrates Z-Node, at (908) 754-9067. 
PC Pursuit users, use the NJNBR outdial. Star- 
Link users, use the 3319 outdial. 
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Relay International Message Exchange 
Forth Conference 

Edited by Gary Smith 

RIME (Relay International Message Exchange) is a PC-board based network similar to FIDO. The original list Forth was pro- 
duced by Bonnie Anthony, sysop of Running Board A— which is RIME central. Hers was only a node list. The Forth conference 
originates on Jim Wenzel's Grapevine BBS in Little Rock, AR. Jim was able to identify all but a few nodes and affbc the phone 
number and system operator associated with each. It's a rather impressive list. 

Messages carried on RIME Forth cor\ference are essentially identical to those carried on the GEnie Forth RoundTable and on 
UseNet comp.lang.forth news feeds. Our apologies for any systems not mentioned. 



Abstract BBS 


ABSTRACT 


Mark Froese 


(718) 


351-7633 


Alpine BBS 


ALPINE 


Jason Hills 


(503) 


581-0923 


Aguila BBS 


AQUILA 


Steve Williams 


(708) 


820-8344 


Baudline II 


BAUDLINE 


Drew Bartorillo 


(301) 


694-7108 


Castle Rock BBS 


CASROCK 


Rocco Fill 


(402) 


572-8247 


The Computer Forum BBS 


CFORUM 


Jim Rhodes 


(804) 


471-3360 


Cloud Nine BBS 


CLDNINE 


Ed Lucas 


(713) 


859-8195 


The San Diego CLIP*BOARD 


CLIPBORD 


Ted Blue 


(619) 


427-4664 


Club PC BBS 


CLUBPC 


Jim Kreyling 


(804) 


357-0357 


Computronics Coinin Link 


COMPTRON 


Ken Hunt 


(813) 


526-1265 


The Consultant's Forum 


CONFORUM 


Bill Raines 


(513) 


424-1861 


Canada Remote Systems 


CRS 


Jud Newell 


(416) 


629-0136 


DFW Programmer's Exchange 


DFWPGMR 


Ric Naff 


(214) 


398-0013 


Digital Schoolhouse 


DIGISCHL 


Richard Munro 


(416) 


299-7306 


The Enchanted Forest BBS 


ENCHANT 


David Rockey 


(904) 


377-2001 


The Godfather 


GODFTHR 


Kathi Webster 


(813) 


289-3314 


The Grapevine BBS 


GRAPEVNE 


James Wenzel 


(501] 


753-8121 


Gwinnett Hospitality 


GWINNETT 


Gene Hysner 


(404) 


962-6820 


Hallucination BBS 


HALCNTN 


Michael Malak 


(703 


425-5824 


the Haven of Rest 


HAVEN 


Byran Pike 


(612 


474-0724 


The Holistic BBS 


HOLISTIC 


Mike McCarthy 


(213 


531-3890 


Data Central BBS 


ICC 


Doug Scott 


(317 


543-2000 


The Icebox BBS 


ICEBOX 


Darren Klein 


(718 


793-8548 


Life Scan Communications 


LIFESCAN 


Kelly Tompkins 


(213 


865-3988 


HHDC BBS 


MEDINFO 


Peter Booras 


(904 


221-9425 


The Mog-Ur's EMS 


MOGUR 


Thomas Tcimpidis 


(818 


366-1238 


Moondog 


MOONDOG 


Don Barba 


(718 


692-2498 


M.O.R.E. 


MORE 


JThomas Howell 


(401 


849-1874 


The Musical Chair 


MUSICAL 


Jeff Woods 


(416 


438-3009 


Network East 


NETEAST 


Howard Hartman 


(301 


942-5616 


O.L. E.F.I 


OLEF 


Peter Grain 


44-8 


L-882->«08 


Programmer's Palace 


PALACE 


Matthew Briggs 


(703 


) 866-4452 


PDS-SIG BBS 


PDSSIGI 


Bob Allen 


(408 


1 270-4085 


The Pegasus BBS 


PEGASUS 


Raymond Clements 


(502 


1 684-9855 


ST. Pete Prograauner ' s Exchange 


PETEXCH 


Bill Blomgren 


(813 


1 527-5666 


PGHSouth PCBoard System 


PGHS 


Dan Deady 


(412 


1 563-5416 


ProPC BBS 


PROPC 


Robert Malakoff 


(412 


1 321-6645 


The Punkin Duster BBS 


PUNKIN 


David Ludwig 


(714 


) 522-3980 


PC Rockland BBS 


ROCKLAND 


Charlie Innusa 


(914 


1 353-2157 


The Round Table BBS 


ROUND 


Daniel McCoy 


(215 


1 678-0818 


The Running Board 


RUNNING A 


Bonnie Anthony 


(301 


) 229-5623 


The Cave 


THECAVE 


Roger Lee 


(408 


) 259-8078 


The Pub BBS 


THEPUB 


Jim Fennell 


(914 


) 686-8091 


The TREE BBS 


THETREE 


Frank Fowler 


(904 


) 732-0866 


Technet At TJHSST 


TJHSST 


Kelly Deyoe 


(703 


) 941-3572 


The Right Place (tm) 


TRP 


Roger Sligar 


(404 


) 476-2607 


The Virginia Connection 


VIRGIN 


Tony McClenny 


(703 


) 648-1841 


Washington PC-Board 


WASHPCB 


Mike Keelon 


(412 


) 225-9782 


The Windows Plus BBS 


WINDOWS 


Russell Jackson 


(501 


) 968-8431 
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YASBEC, from page 7 

What's next 

Designing a project like YASBEC is like writing a pro- 
gram. There aie as many ways to get the job done as there 
are designers. Looking back I always see things 1 wish were 
done different. Unfortunately you can not simply 'edit' hard- 
ware like software, once the choices are made you must live 
with them. Luckily after months of playing with this board I 
have found little I would have done differently. But where 
do we go from here? Well I currently have photo tools ready 
for a backplane and a memory expansion board. But why a 
backplane for a single board computer? Because the one with 
the most toys when he dies wins! Seriously, while the YAS- 
BEC makes a nice system all by itself, it does lend itself to all 
sorts of possibilities with a backplane. YASBEC can support 
two 512K X 8 static RAM chips, but these chips currently run 
around $250 each! Next year they may be affordable but for 
now a memory board would be nice with several 128K x 8 
chips. The memory board also includes a non-volatile con- 
troller and battery for all the RAMs making a nice RAM disk. 
And how about video? Wayne and 1 currently have a proto- 
type video board running. It has resolution and colours simi- 
lar to VGA but with a RAMDAC to provide 256 x 24 bit 
mapped colour. It also has a 256 gray scale real-time frame 
grabber. The frame grabber still needs work but results so far 
are promising. 

Backplane 

Figure 6 shows the backplane pin out and driver chips. 

The pin out of the backplane was determined largely by the 

circuit board layout. While the Eurocard PCB, card cage and 

connector are standard the pin out is unique to YASBEC. U7 



provides the bi-directiorwl data bus while the other four 
74ACT245 chips buffer the address and control lines. Now, 
how many hardware gurus noticed something strange? 
There are four bi-directional bus drivers hard wired uiu-di- 
rectional. Why the overkill? Well, 1 had lots of 245 chips in 
surface mount. 

Software 

Software for the YASBEC is still under development. Be- 
sides a standard 2.2 system and BIOS, a banked system is 
also currently under way. By the time this is in print we 
should have an answer for those people who do not want to 
port CP/M themselves. The best place to stay up to date is on 
GEnie. [Ed.: There are several topics on YASBEC in ttie CP/M SIG]. 

Where do I get one? 
The YASBEC is currently available as a semi-populated kit 
for CDN$100 plus $10 shipping and handling for Canada 
and the USA. Payment by cheque or postal money order, 
sorry no credit cards. You can send your order to my address 
as given in the biographical paragraph to this article. Included 
in the price are the monitor ROM, address decoding PALs, 
and all surface mount components st^ldered to the board. 
Not included are the sockets, socketed parts, cables and any 
leaded parts (jumpers, connectors, et cetera). Along with the 
parts list I have included suggested sources, I'll be glad to 
help if you have trouble finding parts. Assembling this sys- 
tem should prove itself an interesting project for the true 
hacker. Just like the good old days, eh? Anyone interested in 
a fully assembled system in a case with power supply, con- 
sole and software ready to boot should go buy a PC.# 



nDDR_BUS(0!l9![I> 



DflTfi_BUS(Qr7)C 
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Z-Best Software 



What Summer Doldrums? 



By Bill Tishey 



Listing 1 

New Releases: 



DIALER.COM 1.00 



BBS 

HLP=N 

CFG=N 

NTS.COM 
DATE 
HLP=Y 
CFG=Y 



I've been extremely busy the past 
few months as Z-System Librarian re- 
cording a multitude of Z program re- 
leases. Therefore, instead of tips for 
updating the Z3HELP system, which I 
promised in the last column, 1 thought 
it more appropriate this time to list for 
you the recent updates and new re- 
leases. See Listings 1 and 2 for the 
many "new" and "revised" programs. 
I'll comment briefly on some of these 
and describe a few in more detail. The 
listings, by-the-way, are taken from my 
ZFILEVIO.LST. Note the new format 
for the 3-line description which assigns 
a category to the program and indi- 
cates whether a HELP (.HLP) and 
ZCNFG configuration (.CFG) file are 
available for it. I'd like to hear from 
readers about what they'd like to see in 
this column. Such listings could be a 
continuing feature. Let me know what 
you prefer. 

Hal Bower: Hal has released Version 
4.4 of the Libraries which consolidates 
changes to DSLIB, SYSLIB, VLIB, and 
Z3L1B since version 4.3 (L1BS44A.LBR 
in Microsoft format and LIBS44AS.LBR 
in SLR format). The major improve- 
ments have been to Z3LIB's NDR routines. Some additional 
work on DSLIB still remains. 

Gene Pizzetta: Gene has made some minor bug fixes to 
CONCAT (a P2D0S bug) and D ATSTP (display of European 
date with the 'D' option). Also, his ROMAN utility now con- 



Vers S ZSUS Siz Rec CRC Librsiry/SiiBe Issued Author 



2 10 72D3 DIALER 



9 07/23/91 Bruce Morgen 



Allows your coiTfiuter and Hayes-ccn^jatible modem to dial your voice 
telephone calls. Helpful for scripting through banking and other 
touch-tone-based response systems. 

1.00 3 V2/10 5 27 E831 NTSlO 9 06/01/91 Rob Friefeld 
Modified version of NT (Note Taker) which has a single full screen 
editor. WordStar conraajid set. Appends short notes to files, 
including the current time. 



PUSHDIR.COM 1.00 4 18 2CA4 PUSHDIR 8 06/11/91 Bruce Morgen 
DIR Saves the current default user code tjui drive to user registers 
HIiP=N 1 respectively and restores this location as needed later. Vtorks 
CFG=N under all variants of ZCPR3, Z-System, and BGii. 



and 



V2/10 4 29 88D1 TXTALIAS 17 05/20/91 Bruce Morgen 
standalone aliases from standard ASCII source files. 
Similar to ACREATE and BA2 4, but supports assembly-style comnents and 
multiple linefeeds in the source file. Uses latest, built-in ALIASO. 

0.90 V2/10 8 64 CE56 ZDT09 9 07/10/91 Joe Mortensen 
Z-System Day Timer, a daily planning calendar derived from ZDB, 
Autcmatioally reads the real-time clock and displays the current 
day's schedule. Requires ZCPR30+ and extended TCAP. 



TXTALIAS.COM 1.00 
ALIAS "Compiles 
HLP=Y 
CPG=N 

ZDT.COM 
DBASE 
HLP=N 
CFG=N 



ZFIND.COM 1.30 V2/10 4 29 8F94 ZFIND13 34 08/01/91 Terry Hazen 
FILE ZCPR3 string search utility which very quickly finds ASCII strings in 
HLP=Y text files. Found string can be displayed in either line or delimited 
CFG=Y block. Output can be written or appended to a file. 



Bill Tishey has been a ZCPR user since 1985, when he found the right combina- 
tion of ZCPR2 and Microsoft's Soft card CP/M for his three-year-old Apple U+. 
After graduating to ZCPR30 and PCPl's Applicard CP/M, he did a "manual in- 
stall" of ZCPR3.3 (with help from a lot of friends!), and in late 1988 switched to 
NZCOM and ZSDOS, all on the same vintage Apple //+. Bill is the author of the 
Z3HELP system, a monthly-updated system of help files for Z-System programs, as 
well as comprehensive listings of available Z-System software. Bill is the editor of 
the Z'System Software Update Service and has compiled such offerings as the 
Z3C0M package and the Z-System Programmer's Toolkit. Bill is a language analyst 
for the federal government and frequents the Foreign Language Forum (FLEFO) on 
CompuServe. He can be reached there (76320,22), on Genie (WATISHE), on Jay 
Sage's Z-Node #3 (617-965-7259) and by regular mail at 8335 Dubbs Drive, Sev- 
ern, MD 21144. 



verts either way (between roman numerals and decimals) 
and will also run under vanilla CP/M. Gene is now working 
on an update of ZSLIB (version 3.0 should be available as 
you read this). Incompatibilities with DSLIB are being cor- 
rected, command line parsing is being improved, and many 
new routines are being added for date 

and time output. 

Bruce Morgen: Bruce has upgraded a 
number of utilities to Type-4 status 
(TRIM, W), and continues to improve 
others to run more effectively when 
linked as Type-4s (SETPATH, VREN). 
He's added LZH support to the LUSH 
library shell and has done some code- 
crunching on CPA, LCET and PATH. 
He's also implemented in the Z34 tran- 
sient POKE utility word-wide opera- 
tions when a hex number of 3 or more 
digits is used. This is useful with 
ALIAS17 and SALIAS15 and their new 
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pointer capabilities, which return 
word-wide values. POKE can now 
pass such values to system registers for 
use for flow control in subsequent ali- 
ases or with RESOLVE, etc. 

Bruce has also introduced DIALER, 
a nifty little program to automate voice 
telephone calls to touch-tone-based re- 
sponse systems. DlALER-based Z-Sys- 
tem scripts can relieve one of the hassle 
of remembering long banking access 
numbers, etc. It is hardware-independ- 
ent and assumes only that data can be 
sent to the modem via the PUN: device 
and that the modem will allow blind 
dialing (no dial tone or busy signal de- 
tection) and will not wait for a carrier 
before going back on-hook. 

Joe Mortensen: Joe continues to 
tweak his Z-System name and address 
database, ZDB. Version 1.4 is consid- 
erably faster in finding records and 
fixes some problems in screen display. 

Joe has also introduced ZDT, the Z- 
System Day Timer. A derivative of 
ZDB and still undergoing evaluation 
and testing, ZDT is a daily planning 
calendar which automatically reads the 
real-time clock and displays the current 
month's calendar and schedule for the 
current day. Word has it that Joe is 
now working on ZBIB, a "biblio- 
graphic database" patterned after ZDB. 

Terry Hazen: Terry has undoubtedly 
kept busy this summer with updates to 
ACOPY, DSTATS, NZBLITZ, RE- 
MIND, SCAN, and a new release - 
ZFIND (see below). 

At the urging of Howard Schwartz, 
Terry has expanded the status message 
of ACOPY's 'Update' option to indi- 
cate whether an older file as been re- 
placed or not when a file is over-writ- 
ten. A file with no datestamp is auto- 
matically 'Dated', while one with an 
older stamp is 'Updated'. An update 
failure now either produces the mes- 
sage "No Update (Source Older)" or 
"No Update (Same Date)". DSTATS, a 
derivative of DSKMAP and UMAP, 
now displays the following additional 
disk statistics: the maximum number 
of disk directories, (in each user-area 
display line) the amount of space used, 
and (in the "Free:" summary line) the 
amount of disk free space. NZBLITZ, 
which saves and loads NZCOM system 
Images, is now ZCNFG-urable, allow- 
ing a choice of image saves 1) up to 
CBIOS, 2) up to a specified address, or 
3) up to the top of memory. The 
NZCOM.CCP file produced by the 
NZBLITZ loader can also be flagged as 



Listing 2 
Revised Programa: 



Name 



Vers S ZSUS Slz Rec CRC Library/Size Issued Author 



AC0PY.COM 3.30 3 6 46 EB5F ACOPY33 26 07/21/91 Terry Hazan 
FILE Attribute Copy program. General file copy tool with source and 
HLP'Y destination disk directory caching. ACOPY. PAT has patch locations. 
CFG-N Derived frcm PPIP vs 1.2. 



1.50 4 na na na CLEDIS 
ZCPR34 resident ccnniand line editor. 



38 07/23/91 Rob Prlefeld 



CLED 
RCP 
HLP=Y 
CFG=N 



CCMCAT.COM 1.40 7 52 B373 C0NCAI14 43 05/29/91 Gene Plzzetta 
HP Concatenates two or more source files Into a destination file, 
HLP=Y similar to PIP, or appends them to an existing file. Accepts both 
CFG^Y DIR and DU specs. Checks for adequate disk space. For ZCPR3 only. 

CPA.COM 1.30 4 32 49B4 CPA13 20 07/05/91 Bruce Horgen 

FILE CovnPare Aacii utility to analyze two files, on a line by line basis, 

HIiP=Y and report any differences. Vs 1.0 (01/87) by Malcolm Kemp. 
CFG=N 

DATSTP.COM 1.50 5 37 A66B DATSTP15 70 05/27/91 Gene Plzzetta 
DATE Displays or changes the create and modify date stands on any file 
HLP=Y frcm the ccnmand line. Universal version (ZSIXIS/ZDDOS/ZRDOS with 
CFG=Y DateStamper, under Z3PLUS will display but not change datastamps ) . 

DSLIB.REL 4.40 4 V2/11 6 44 3905 LIBS44A 65 06/30/91 Hal Bower 
PROGl Routines to facilitate addition of file time- and datastamplng and 
HLP»Y real-time clock features. Microsoft REL foimat. 
CFG=N 

DSTATS. COM 1.10 2 16 DF42 DSXATSll IB 07/23/91 Terry Hazen 
DISK ZCPR3 disk/user statistics utility. Displays disk block size, disk 
ULP'^Y capacity, allocated and free space, list of active user areas, etc. 
CFG-Y Ccmblnes DSKMAP and many functions of UMAP. 

DU.COM 3.50 12 91 496C DU35 62 07/21/91 Jay Sage 

DISK ZCPR3 Disk Utility. Similar to vs .4, but can be patched to operate 

HLP=N under standard CP/M as well as Z-Systam. See DU.COM vs 3.14. 
CFG=N 

HELPC.COM 1.30 5 36 98B9 HELPCia 23 06/20/91 Howard Goldstein 
HELP Replacement for the standard Z-Syatem HELP utility. Handles crunched 
HLP=Y as well as normal, uncanpressed help files. Print options are 
CFG=Y disabled when wheel byte is turned off. Configurable with ZCNFG. 

JETCP.COM 1.20 4 26 E78F JETCP12 17 06/08/91 Carson Nllson 
FILE A fastest-possible speed file copy program for Z3PLUS only. Multl- 
HLP=Y sector I/O and advanced BDOS error-handling. Copy buffers are as 
CFG=N large as memory will allow. Preserves CP/M Plus datestamps. 

LGET.COM 1.30 4 29 3B20 LGET13 4 07/20/91 Bruce Morgen 
LBR Extracts specified files frcm an Indicated LBR. Vs 1.0 by R. Conn. 
HLP=Y 
CFG=N 

LUSH.COM 1.20 4 4 26 1150 LUSH12 24 07/26/91 Bruce Morgen 
SHELL Library Utility SHell which takes advantage of the extended services 
HLP=Y of ZCPR33+. 
CFG=N 

NAME.COM 1.20 4 V2/10 2 11 E793 NAME12 9 06/30/91 Bruce Morgan 
NDR Renames aind deletes directory names on-the-fly. Inspired by Jay 
HLP=Y Sage's ARUNZ script for the same function. 
CFG=N 

NZBLITZ.COM 1.40 4 V2/10 2 IS A97B NZBLTZ14 22 06/23/91 Terry Hazen 
SYS NZCOM utility which saves and loads system Images. Allows fast cold 
HLP=Y load of a system - full up with desired drivers, path, options, etc. 
CFG=y Configurable with ZCNFG. Vs. 1.0 by Cam Cotrill. 

PATH. COM 3.20 4 2 12 08CE PATH32 9 06/07/91 Bruce Horgen 
SYS Allows the user to display the current path or set a new path. 
HLP=Y Ccinmand line quiet option. Z80 required. Vs 3.0 (4/12/84) by R. 
CFG-N Conn. 
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P0KB.COM 1.10 4 V2/10 
SYS Trantlent nplaceoi 
HLP-Y SOOOh. 
CFG-H 



2 9 A84B POKBll 7 07/12/91 Bruce Morgen 
int for -the RCP-based POKE ccnmand. Type 3 at 



REMIND.COM 1.40 5 40 3FB7 REMIND14 36 07/21/91 Terry Hazen 
DKCB i^tpolntmant ramlndar utility for ZCPR3 euxJ ZSD06 with clock . Will 
BIf-Y display and optionally print a (ortad and paged llat of dated aj^ 
CFG-y ivailiider line* with optional tine entriei frcn a text dataflle. 

ROHAH.COM 1.00 4 V2/10 2 16 4000 ROMANIO 14 06/01/91 Gene Plzzetta 
HP Z 'if lad veraion of R0MAH.COM (10/78 by M. Pedder) which converta 
HlfaY b e twe e n decimal nusAsera and Roman nunerala. Worka frcm ccnmand line 
CFG^Y or in interactive node. 

SCMJ.COM 2.40 6 47 46C0 SCAN24 100 06/12/91 Terry Bazen 
FII2 Bi-directional, video-oriented text file display utility that uses 
Hlf-y the basic WordStar ccnmand set to control viewing. 
CFG-Y 

SC0PY.COM 0.60 4 IS 114 B6AB SCOPY06 30 06/01/91 Rob Frlefeld 
FIU Screen-oriented file-copy utility. Displays source and destination 
BLP'Y directories in vertical windows. ZF-like conmands. Supports file 
CFG>Y selection and copy by datestaiq). Extended TCAP required. 

SBTPMB.COM 1.10 4 4 27 D71E SETPTHll 20 06/07/91 Bruce Morgen 
SYS Enhanced derivative of PAIB.COM which allows adding/deleting elements 
BLP'Y from either end of the path. Vs 1.0 (3/8/87) by R. I. Demrow; derived 
CFG^ froB PATH vs 3.0 (04/84) and PATH 1.0 (01/83) by R. Conn. 

SYSLIB.REL 4.40 4 V2/11 22 173 7F7B LIBS44A 65 06/15/91 Hal Bower 
PROGl Upgrade of SYSLIB 4.0 for Z80 ccn«>atlble ccoputers. Microsoft REL 
BIf-Y format. 
CFG-H 

TRIM.OOM 1.10 4 2 10 875F TRIMll 8 07/09/91 Bruce Morgen 
PR0G2 Truncates .COM files at a requested address. Used to delete 
HIf«Y unneeded D6EG from the output of linters lilce LINK, L80, ZLINK. 
CFG-N Type 3 at SOOOh. 

UNZIP.COM 1.50 C 15 119 8D13 UNZIP15 23 06/01/91 Howard Goldstein 

LBR Extracts all menibers of a specified .ZIP file matching <afn>. If 

HLP4 <afn> is not present, a directory of the .ZIP file is displayed. 
CFG-41 

VLIB.REL 4.40 4 V2/11 6 44 DD58 LIBS44A 65 06/16/91 Hal Bower 

PROGl Library routines for basic CRT screen manipulation as well as extended 

HIP-Y graphics routines. Microsoft REL format. 

CFG^ 

VREN.COM 1.10 4 V2/10 4 27 3A4A VRENll 31 06/05/91 Bruce Morgen 
FII2 Visual File REHamer. Provides interactive renaming of files with 
HLP-Y format checking. Vs. 1.0 (8/8/88) by Bruce Morgen. 
CFG-il 

W.COH 2.40 4 4 32 A6F2 W24 30 07/03/91 Bruce Morgen 

FIU! Wildcard Shell Processor that enables wildcard processing for 

HIf>Y programs that do not usually accept wildcard parameters. 
CFG-H 

X0X.COM 1.0k 4 12 93 C359 XOXIOK 27 06/01/91 Rob Frlefeld 

FIU! Text file viewer with additional functions for listing blocks, writing 

BIf-Y blocks to disk, 4 msrglng files. Does not uncompcesa files or access 

CFGii^l libraries. Follow-on to VIEW.COM. Requires extended TCAP. 

Z3LIB.REL 4.4a 4 V2/11 11 88 A768 LIBS44A 65 07/14/91 Hal Bower 
roOGl ICPR3-specific library routines. Microsoft REL format. 
HLP-Y 
CMGi« 

ZDB.COM 1.40 8 64 DB21 ZDB14 31 06/28/91 Joe Mortensen 

DBkSE Small, fast nans and address file manager with built-in label and 

Hlf-Y envelope addressing features. Requires extended NZTCAP. 
CFG-Y 

ZFILBR.COM l.Op 4 15 116 51B7 ZFIOP 105 07/27/91 Rob Frlefeld 
FILE Enhanced version of VFILER designed to take advantage of ZCPR33-t- 
Hlf-Y facilities. S-col, reverse video, DateStzunper version. 
CFG-N 



a system file and/or archived file. Any 
pending multiple command line in the 
old system is now saved and appended 
to the loader MCL, a feature which 
should allow for some interesting use 
of loader files in aliases. 

Major enhancements to REMIND 
are the inclusion of a calendar display 
at startup, along with the option ("/l- 
12") to display a calendar and upcom- 
ing reminders for a specified month 
only. Screen paging is also now an op- 
tion (allowing it to be turned off when 
sending reminders to a printer). 

Terry has also added speed, 
smoothness and an improved screen 
display to SCAN, his bi-directional 
text-file viewer. Use of a modified 
Boyer-Moore search algorithm also 
now results in faster string finds. Rob 
Friefeld: Besides a significant update to 
ZFILER (see below), Rob brings us 
NTS, a modified version of Note Taker, 
as well as updates to CLED (see below) 
and his screen-oriented utilities SCOPY 
and XOX. Rob is also working on en- 
hancements to LSH, his now-famous 
command-line history shell. 

Improvements to SCOPY include a 
new command to RELOG the current 
source/ destination/mask, some fixes 
to the Zip command, and a new Group 
Zip command to copy all tagged files 
to an alternate directory. "Z" and "GZ" 
now act more like ZFlLER's "C and 
"GC commands. 

ZFIND.COM vs 1.3 (ZSUS Vol 2 #10) 

Terry Hazen's new ZFIND utility is 
a string-find tool styled after Irv Hoff s 
FIND.COM, orJy much faster and more 
powerful. 

ZFIND will find one or more ASCII 
strings in a group of wildcarded ASCII 
text files. Searches are performed in a 
16k text buffer, using a modified ver- 
sion of the Boyer-Moore string-search 
algorithm. When a matching string is 
located in the buffer, the line contain- 
ing the string is displayed, in either the 
line or the delimited block in which it 
was found. The entire buffer is first 
searched for stringl and the finds dis- 
played, then the buffer is searched for 
string2 and those finds displayed, etc. 
When the buffer has been searched for 
all strings, the next buffer-full is read 
in and the process repeated. The same 
process is repeated for each file that 
matches the specified ambiguous file- 
name. Since the search process ignores 
lines except to display the found string, 
line number output is not provided. 
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ZP.COM 

FILE 

HLP=y 

CFG=Y 

ZS.COM 
LBR 
HLP=N 
CPG=N 



See Figure 1 for ZFIND's syntax. 

Certain characters may be used dur- 
ing string entry to enter sjjecial charac- 
ters into the search string: a question 
mark matches any character in that po- 
sition; an underline character is 
changed to a TAB; and a backslash is 
changed to a line feed, allowing 
searches for strings starting at the be- 
girming of a line. Output can also be written or appended to 
a file. Searches are normally performed ignoring case; how- 
ever, if you don't specify a string on the command line, one 
is requested, allowing you to enter the string in the exact case 
desired. Terry provides several sample applications for 
ZFIND in his included help file (ZFIND13.HLP). Single-line 
index files are simplest to search. The alias "LOOKUP zfind 
dirmast.cat $*", for example, will perform fast filename 
lookups in MAST.CAT files. Block-display applications, 
however, Eire also easy. The 'B' option, for example, allows 
lookup of keywords in *.FOR files, displaying the entire FOR 



1.40 4 8 64 5BD8 2P14 95 07/17/91 Terry Hasen 
ZCPR33+/Z3PI.US Bcreen-oriented flle/disk/memory record patcher using 
the ZPATCH command Bet. Rfiquiree a VLIB4I>+ Z3TCAP. One- record 
cache can be exchanged with file/disk/memory recordB. 

1.10 14 105 rF2A ZSll 47 06/28/91 Pete Pardee 
Z 'if led verBion of Dave Rand's NSWP207 with NDR support and ability to 
act upon the current file with any Z-Syetem ccmmand up to 127 charB. 
Requires ZCPR33+ with extended TCAP. 



Figure 1 

B0:fKIRK>ZFIND // 

ZFIND String Find Utility vers 1.3 
Syntax: 

ZFIND [dir:]afn [Btring(B)] [>outfile] [/options] 
If no string is included, one will be requested, 
permitting a search for lower-case characters. 
Special string characters: 

" I " separates multiple search strings 
"7" matches any character 
"_" matches a tab character 
"\" matches the beginning of a line 
Options : 

U - Search files on all user areas 

A - Display all files searched 

C - Display found string line in context (3 lines) 

B - Display found string line in a delimited (LF, "-" ) block 

D - Don't Page screen display 

>[dir:]outfile - Output to file 

»[dir:]outfile - Append to file 



messages for a specified filename. The same option can be 
used to search ZFlLEVxx.LST, RCPMxxxx.LST and similarly 
delimited lists. ZFIND's faster search speed and ability to 
output/append to a file would appear to make it more pow- 
erful than XFOR for such applications. 

Since ZFIND is ZCNFG-urable, default configurations can 
be created for a wide variety of applications. To create a 
'card' file of topic or article paragraphs, for example, where 
each paragraph contains keywords and topic summaries, de- 
scriptions, etc., simply configure ZFIND to use ODh (CR) as a 
delimiter. ZFIND will then display the matched strings in 
single-spaced paragraphs. To create a version of ZFIND 
which always searches all user areas on 
the specified or default drive, simply 
set the 'U' option test to always true. 



fixes to some pesty filecopy bugs, the following changes and 
additions are worth noting: 

1. ZFIOP.LBR is a hefty file (105k), and includes the usual 
separate versions for display of 4 or 5 columns of files, dim 
or reverse video, and support for DateStamper. It also, how- 
ever, contains 1) a complete version history since its prede- 
cessor, VFILER 4.2, 2) the text of Jay Sage's TCJ articles (is- 
sues 36 and 37) detailing the functions of ZFILER, and 3) an 
addendum updating Jay's material. The latter contains notes 
on Group Macro scripting which many have been seeking 
since version 1.0m. Such attention to documentation was par- 
ticularly thoughtful, but then, this has been a trademark of all 
of Rob's work! 

2. ZFILER is now ZCNFG-urable. An included ZCNFG 
(.CFG) file handles complete configuration except for macro 
string installation. Three screens allow setting of general de- 
faults as well as specific "macro-related" options. "General" 
options include a toggle for uppercase display of filenames 
and another for "clear screen on exit". (The latter should be 
good news to those who've ever run a macro command from 
ZF1LER.CMD, then, as ZFILER reloaded with the "Strike Any 
Key" prompt, watched it clear the screen of any message 
from the program that had just run before you could read it!) 
"Macro-related" options allow setting of the search path or a 
fixed DU: for ZF1LER.CMD and ZEX batch files. Another 
option allows erasing of a .ZEX file after a shell run. (Of 
course, you'd only want to set this once you've debugged 
your macro command file!) 

3. ZFILER's Group Tag/Untag commands now operate 
from the file pointer to the end of the file list, rather than on 
the entire list. Thus, if you go to mid-screen and press "GT", 
only files from the cursor position to the end of the file list 
will be tagged. This is a restoration of how ZFILER used to 
work. 

4. The Group Macro now puts the tagged file count into a 
configurable user register before running. This allows the 
macro to downcount and take some additional action after it 
has run on each tagged file. As a sample application, Rob in- 
cludes the following macro, which creates libraries of 
crunched files (thanks to Lindsay Haisley for pushing for this 
feature!): 

1 I $d?u:;$Icrunch $f Hl:;reg ia5;if reg 5" 0;$''Library DO ":; 
Iput $-Library Name: " Ml:*.* +l;era Ml:*.7Z7;fi;$h: 



ZFILER vsl. OP 

Rob Frief eld's update of ZFILER, 
the ZCPR3 file-maintei\ance shell, has 
been much anticipated. The last update 
(vs l.Oo) by Caison Wilson was nearly 
two years ago, so there was much on 
Rob's list for improvement. Besides 



Figure! 

Syntax: CI£D 

CLED 
If ' 






run once only (e.g. frcn a shell such as ZFILER) 



The default control key set includes these important ccmnanda: 

OR - execute conmand line 
ESC Q - pop the BhoU 
ESC S - toggle recording on/off (prcoipt showB >/» to indicata state) 

^W - recall ccnimand lines frco history stack 

*E - recall history in reverse direction 
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Typing ''G<ESC>1'' will crunch all tagged files to a fixed 
directory Ml: (on a RAM disk), make a library out of them 
(leaving room for one more file) with input for library name 
and location, then erase all the crunched files. [Note that REG 
must be a Type3 or Type4 program (or RCP) for the ZEX GO 
"$!" to nin CRUNCH repeatedly. Also remember that regis- 
ters oiJy hold a 255 count! For consistency, single macros put 
a "1" count in the user register. ZFILER will also allow use of 
the full register range (0-31), although one should be aware 
that 10-15 are reserved and 16-17 are used by other pro- 
grams.] The only complaint remaiiung about ZFILER which 
I've heard of is its failure to filter output generated by the 
view fuiKtion. Certain escape sequences when not trapped 
can wipe out a terminal (even reset the configuration stored 
permanently in RAM). Rob may address this problem in a 
future update. 

CLEDvsl.5 

Rob has also updated his memory-resident command line 
editor (CLED), originally distributed with Z34RCP11.LBR. 
Installed as part of an RCP, CLED adds the features of cursor 
movement, insert/ delete, and record/recall of command 
lines to your Z34 CCP. It is a ZCPR "shell" (using up one 
shell stack entry), and thus will reinvoke itself automatically 
following any ZCPR command. If a ZS/ZDDOS, DateStam- 
per, or Z3PLUS clock is implemented, the command prompt 
will show the system time. See Figure 2 for CLED's command 
syntax. 

CLED15.LBR includes two companion programs. An in- 
stallation program, CLEDINST, allows you to set up CLED to 
your preference. The RCP can be installed directly in mem- 
ory for testing, and then saved to a file with an image-saver 
such as SNAP or NZBLITZ. The segment image can also be 
saved with command lines already loaded. 

CLEDSAVE, a history save/load tool, writes the contents 
of the history stack to a text file on disk. This file can be 
reloaded later (CLEDSAVE <file> L), or composed in ad- 
vance with a text editor, then loaded. CLEDSAVE is useful in 
a startup alias to load frequently used command lines from 
an easily edited file. 



See the Z-Message Base below for instructions on assem- 
bling an RCP to implement CLED. Note that the RCP must 
be assembled from scratch, loaded with JETLDR, then saved 
with NZBLITZ. You can't simply load the new RCP into an 
old NZRCP.2KL file. If you don't have an assembler, there 
are many users who would be happy to create the CLED- 
RCP segment for you. Simply decide what you want in your 
RCP and how many records you have allotted and drop a 
note to the editor or myself with your system specifics. 

Z Message Base 

2-Node #2, 07/26/91 CLED15.LBR 

Question: I'm interested in implementing the improved 
CLED editor. What do I assemble the RCP with and how do I 
select the part to be assembled? 

Answer: Here are the steps to implement CLED 15 in a Z34 
RCP. The SLR assembler or ZM AC will do. 

1. You need all the source code distributed with 
Z34RCP11.LBR. 

2. Edit Z34RCP.LIB 

Find the configuration information "CLED Command" 
and replace it with Z34RCP.1NC in the CLED 15 library. Look 
through the section to set up the history size you want. 
(Kaypro users should put in the Kaypro EREOL screen code 
(18H?) to save lots of bytes.) 

3. Assemble the RCP: 

AO:>SLR Z34RCP11/6 

The assembler will prompt you for which modules to in- 
clude. (My 18 record RCP has room for CLED, ECHO, ERA, 
CLS, and some little custom ditties.) ZMAC Z34RCP11 also 
works, but the prompts are a bit scrambled. 

Just type a Y or N if you want a module or not. 

4. Load the .REL (rename to .ZRL if you prefer) file with 
JETLDR and it is running. 

5. Run CLEDINST to install your command set in the 
RCP. 

6. Save it with NZBLITZ or SNAP. (Rob Friefeld) • 



Reader, from page 2 

ommend) speaks of the need for "value-added differentia- 
tion"— some difference that makes your product more valu- 
able than the others. I thirdc TCJ has this.. ..but it took me 
over an hour (and two drafts) to be able to put even part of it 
in words. 

Perhaps TCJs problem is image. Peters also points out 
that successful enterprises need a vision: a short, clear, 
understandable statement of mission and purpose. I think 
that, until the last issue, TCJs vision has been a bit murky; 
and this translates into prospective subscribers not being re- 
ally sure what TCJ is for. (Issue 51 has started to change this, 
with the ad on the back and also with your Editor's Desk.) A 
clear vision is a message you can promote, an idea you can 
sell. 

Some famous producer once said, "if you can't write your 
[story] idea on the back of my business card, you don't have 
a dear idea." It's a good target to shoot for. 

B.R. Toronto, ON 

You identified the TCJ reader quite well: embedded systems 



developers, serious hobbyists, experienced CP/M users and novice 
Forthers. This is a market I am comfortable with. However, you 
say, "low-budget hackers who 'cross-specialize' in both hardware 
and software, who like to tinker and know everything about how 
their computers work, " (people like yourself) are a dying breed. Is 
this to say "the barn storming days are over?" Look at any wheat 
field in Kansas. There are still biplanes earning a living every day 
of the year. We may not represent the main stream, but we are and 
always will be a necessary part of the whole. As long as there are 
chips on boards and boards in systems, someone has to know what 
they do. 

Luckily, TCJ doesn't need many such people to be a commercial 
success. BYTE has a circulation of 450,000. One percent of this 
would be a good number. Do you think in all the computer indus- 
try there are still 4,500 people like us? 

"If you can't write your idea on the back on my business card, 
you don't have a clear idea. " Try this: 

"TCJ serves the entrepreneur in embedded controls and the se- 
rious computer hobbyist desiring to learn software and hardware 

See Reader, page 50 
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TC J """"^^ Computer Journa l Market PlacG 



THE STAUNCH 8/89' er 

Support for Heathkit 

H-8 and H/Z-89 Computers: 

Bimonthly Newsletter, 

Z-System & HDDS Systems, 

CP/M and HDOS Utility and 

Applications Software. 



THE STAUNCH 8/89 'er 

c/0 K1rk L. Thompson 

P.O. Box 548 

West Branch, lA 52358 

Voice: 319-643-7136 

(eves and weekends) 



Advent Kaypro Upgrades 



TurboROM. Allows flexible configura- 
tion of your entire system, read/write 
additional formats and more. $35 

Hard drive conversion kit Includes 
interface, controller, TurboROM, soft- 
ware and manual — ^Everything needed 
to install a hard drive except the cable 
and drivel $175 without clock, $200 
with dock. 

Personality Decoder Board. Run more 
than two drives, use quad density 
drives when used with TurboROM. $25 

Limited Stock — Subject to prior sale 



Call 916-483-0312 eves/weekends or 

write Chuck Stafford, 4000 Norris 

Avenue, Sacramento CA 95821 



CP/M SOFTWARE 

100 page Public Domain Catalog, $8.50 plus $1.50 shipping 
and handling. New Digital Research CP/M 2.2 manual, $19.95 
plus $3.00 shipping and handling. Also, MS/PC-DOS Soft- 
ware. Disk Copying, including AMSTRAD. Send self addressed, 
stamped envelope for free Flyer, Catalog $1.00 

Elliam Associates 

Box 2664 

Atascadero, CA 93423 

805-466-8440 



yigyThe Computer Journal Market PlaCB 

Advertising for Small Business 



Looking for a way to get your message across? 
Advertise in the Market Placel 



First Insertion: 
Relnsertions: 



$50 
$35 



Rates include typesetting. Payment must accom- 
pany order. Foreign orders paid in US funds 
drawn on a US bank or international money order. 
Resetting of ad constitutes a new advertisement 
at first insertion rate. Camera ready copy from 
laser printers, photo typesetters, etc., are accept- 
able. Dot matrix, daisy wheel, typewriter output 
not accepted. Inquire for rates for larger ads if 
required. Deadline is eight weeks prior to publi- 
cation date. Mail to: 

The Computer Journal 

Market Place 

PO Box 12 

S.PIainfieldNJ 07080-0012 USA 



For: CP/M Users with a sense of humor 



WHILE YOU WERE OUT 



Mr Bradley 



of: Small Computer Support 



Address: 24 East Cedar Street 
Newington. CT06111 



[ ] caKed for you 

|x] slopped by 

|x| wanis to hear from you 



Message 

Remember Pieces of 8? Its back, better than 
ever as Eigtit Bits & Ctiaiige, a bimonthly 
newsletter filled with tiumor. tutorials, graphics 
and fine technical articles. Only $t5 per year 
in the U.S. ($18 in Canada and $21 foreign.) 
Subscribe today! Satisfaction guaranteed! 



Z-System Software Update Service 

Provides Z-System public domain software by mail. 

Regular Subscription Service 

ZaCOiVl Package of over 1 .5 MB of COM files 

Z3HELP Package with over 1 .3 MB of online documentation 

Z-SUS Programmers Pack, 8 disks full 

Z-SUS Word Processing Toolkit 

And More! 

For catalog on disk, send $2.00 ($4.00 outside North America) 
and your computer format to: 

Sage Microsystems East 

1435 Centre Street 
Newton Centre MA 021 59-2469 
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Real Computing 

X-10 Revisited, Macli, IVIInix, and Desqview/X 



By Rick Rodman 



x-10 Revisited 

In issue #48 I wrote glowingly of the X-10 Powerhouse 
computer interface, known as the CP-290, that "any X-10 
commands which come across the line are converted to 
status messages that the computer can see". Mike Morris 
writes: "1 have a CP-290, and mine does not produce these 
messages when I push a button on a manual controller." 

After some experimentation emd consulting with the X-10 
gurus at Home Control Concepts, I have to admit Mike is 
right. The CP-290 does report to the computer when buttons 
are pressed on it itself, but it doesn't report codes that come 
over the wire. It is a send-only, unidirectional device. 

Actually, the plot's even thicker than that. Manual control- 
lers, like the wall switch modules, don't send codes at all, 
they only receive them. There is no way for a central control- 
ler to know whether a user has manually turned a light on or 
not. 

There is another computer interface available, which is 
called the TW-523. This device has an optoisolated TTL-level 
interface which can be operated through parallel input and 
output bits. It's "dumber" than the CP-290— it has no battery 
backup or timers — but it's bi-directional: the computer can 
send or receive any X-10 code over the power lines. Remem- 
ber, the manual buttons on the wall switch units don't send 
any code. However, you can receive codes sent by other con- 
trollers or by motion detectors. 

If you're planning a system controlled by a dedicated 
computer, the TW-523 sounds like the way to go. It's avail- 
able from Home Control Concepts for $30. It's also available 
as part of a Powerline Interface Kit for $69, which includes a 
C library and sample code as well as a cable for cormection to 
a PC parallel or serial port. 

HCC also has available some wireless motion detectors. 
These detectors send an on-code when motion is detected, 
and an off-code when motion stops, through the same base 
unit used by the wireless hand control. Because they're wire- 
less, you can put them anywhere — out in the yard, garage, 
parapet, moat, wherever. Because they send a code, you can 
not only turn on a light or sprinkler system, you can also 
delect the code in your TW-523 and activate a voice synthe- 
sizer or camcorder, or switch speakers cormected to the ste- 



Rick Rodman works and plays with computers because he sees that they are the 
world's greatest machine, appliance, canvas and plaything. He has programmed 
micros, minis and mainframes and loved them all. In his basement frill of aluminum 
boxes, wire-wrap boards, cables running here and there, and a few recognizdile 
computers, he is somewhere between Leonardo da Vinci and Dr. Frankenstein. Rick 
can be reached via Usenet at uunet'.virtechlrickr or via 1200 bps modem at 703-330- 
9049. 



reo, or anything else. 

Mike Morris suggests some neat applicatioi« for X-10: "I 
want to be able to turn on the sprinklers when the ground 
gets dry or if the burglar is leaving, but not the day after a 
rainstorm. I want to run the dishwasher after everybody goes 
to bed, then turn the water heater off but back on an hour 
before I get up. And divert the clothes dryer exhaust into the 
furnace air intake when appropriate so the furnace grabs the 
preheated humidified air." 

Mike £ilso provided some "from the trenches" information 
on X-10: "The X-10 signal can have problems 'jumping' 
across the two halves of a 220 volt household circuit. I ended 
up acquiring a capacitor of the proper value, installing it in a 
220v plug and plugging it in. 'One of these days' I'll install 
the Leviton capacitor module in the main electrical panel, but 
for now, it works." 

If you're planning a system controlled 

by a dedicated computer, the TW-523 

sounds like the way to go. 

He also points out that some X-10 lamp modules "forget" 
their brightness setting and will "creep" up or down over 
several hours, and suggests "refreshing" their settings peri- 
odically. (That'll also solve the problem of people using the 
manual buttons — and staying too long in the bathroom, too!) 
He points out that the CP-290 doesn't keep accurate time, 
losing about an hour per month. Mine has forgotten its house 
code a couple of times. "The battery compartment in the CP- 
290 does not have a barrier between the battery and the cir- 
cuit board. Mine leaked and ate away a few traces, which I 
repaired with a small soldering iron and 30 gauge wire." 

Not only X-10, but the whole field of home automation is 
booming in popularity these days. The CE Bus, a fully-bi- 
directional superset of X-10, is coming. I'll venture a guess 
that the reasons for this sudden interest are (a) the increase in 
crime, especially senseless violence and vandalism, (b) higher 
energy costs, and (c) it's inexpensive and loads of fun! 



Mach on the PC-532 

Carnegie-Mellon has released a 
"Micro-Kernel" for Mach which con- 
tains no AT&T code. If you have ftp 
access (which I don't), you can get it 
and play with it. It's called a "micro- 
kernel" because it includes no I/O or 
utilities. A "UX server" task, made ap- 
parently of pieces of Unix, is run to 
provide the missing capabilities. Some 
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Reader, from page 47 
applications.' 
Did it fit?— Ed. 

I think the author of the preoious letter said it well. I'm sure 
what 1 look for in a magazine, but I think I recognize it when I see 
it. I sure did like MicroComucopia. TCJ and CCI are my re- 
placements for it, but TCJ wins out ivith its Forth coverage. I liked 
DDJ in the early days, loved Kilobaud and the early Byte. Kilo- 
baud is dead and Byte might as well be. The common thread 
seems to be hardware, and hardware that can be buUt and fooled 
around with on a limited budget. Obviously I like software too. 
Maybe we are a dying breed. I hope we with an interest in both 
hardware and software are not. I think magazines such as Popular 
Electronics, Radio-Electronics, whatever, even though they tend 
to be criticized for poor technical content, suggest that there is a 
good target audience out there for TCJ. If so, how do we reach 
them?— Frank Sergeant, Contributing Editor. 



I am glad I made it to the Trenton Festival this year: be- 
sides meeting you, Al Hawley, Ian Cottrell, Howard Gold- 
stein, Bruce Morgen and Harold Bower for the first time, it 
broke the sense of isolation I sometimes feel in this remote 
comer. I found a lot of commonality with what Bower is 
engaged in and hope to set up some exchanges with him. 
Looking forward to further developments on banked systems 
and new Z-180/280 boards! 

L.V.H. Mill Creek, WA 

The Trenton Festival is a great way for CP/Mers to get to- 
gether, and it was a pleasure meeting you, too. There were some 
unfortunate oversights on the part of the sponsoring clubs but we 
got on pretty well despite that. Talk is that there will be a special 
banquet for 8-bitters next year. Bob Dean and I have been ap- 
pointed joint ring-leaders to get it organized. Be looking for more 
information in the next few months. — Ed. 



Enclosed is a check for $25 US. The reason it is more than 
you asked for is to allow for the extra aggravation you may 
experience. I recently learned American publishers are run- 
ning up against our Customs bureaucrats.... 

I see future use for old CP/M machines dedicated to 
monitoring and controlling homes and offices such as Jay 
explained in his articles. I would be particularly interested in 
more articles, particularly concerning building systems con- 
trol/monitoring such as heating, ventilation and security 
checking. It would be beneficial to call up your place during 
a winter storm and check out the furnace or verify against 
unauthorized entry before calling the police. 

I would like to see an article dedicated to RS232 standards, 
conunon usage with peripherals and those inevitable devia- 
tions irom. standard, as Art Carlson asked about earlier. 

Keep up the good work, we readers do care. Some of us 
just do not communicate the fact often enough. 

P.C. Edmonton AB 

Thank youl I haven't any problems yet, but will be watching. 

I like your idea of CP/M boxes to control the home. But don't 
limit yourself to using a general purpose computer. Many of the 
embedded controller types who frequent these parts can cook up 
quite a system with an F68HC11, 8031, Z8 or similar. 

Thanks for your letter. You are right, the authors need your 
feedback and so do I! — Ed. 

I am operating under TurboDOS. Any chance of a TDOS 



article? 

H.R. Philadelphia PA 

Good question! Requests have also been received for articles on 
CDOS and S-100. S-100 Buss dropped S-100 support, of all 
things! Any takers? — Ed. 



My company is spearheading an effort to develop a SCSI 
host adapter for the Zenith Z-100 computer and I noticed that 
some of your back-issues have articles relative to this project. 
Please send issues number.... 

P.F.H. New Port Richey FL 

Your issues are on their way. Keep us posted on your progress 
with the Z-100 project. Soun^ like something we'd be interested 
in.— Ed. 



I have a Kaypro 4+88. Is there anything past MS-DOS 125 
for this machine? Also, has anyone replaced a Z80 with a 
Z280? 

P.B. Broadview IL 

I'm afraid you can't pop a Z180 in place of a Z80. Though the 
'180 is software compatible, it is not compatible on the hardware 
level. Have you been following the YASBEC articles? — Ed. 



Got the magazine a few days ago. I'm impressed. It has a 
good format and the articles are well done, informative and 
useful. I'm quite new to CP/M and the Z-System so some 
things were just a little over my head, but that just means I 
need to work with the computer more to gain a good level of 
knowledge. I have found the CP/M group here in Portland. 

As for the handwritten letter, it was a nice change from 
the normal mass produced standard form letter. 

R.D.W. Portland OR 

Thanks for the compliments! Yes, we are blessed with great 
authors. I like your attitude about learning more to reach the level 
of the articles rather than pulling the articles down. Can't learn 
that much. 

Note to others: Richard noticed that I have never bought a 
typewriter. I wrote a handwritten letter to him. One day I may 
spring for a Selectric though I really prefer to stay with state-of- 
the-art technology, like 8-bit machines.... — Ed. 



How about some material on the old CP/M Kaypro 11/ 
IV's? I may even have some to contribute! 
F.G. East Greenville PA 
You're on, Frank! Let's see what you have in mind. — Ed. 



I'd like to see articles on X-10 software, hardware and 
interfacing; sound generators and voice synthesizers. 
R.D. Longueuil QU 
I agree and am hoping to see some good submissions. — Ed. 



My primary attraction to TCJ is as a "last bastion of 8-bit 
computing," much as Jay Sage has represented on the 
Internet and in his announcements on Z-Node 3. Over the 
course of the year, however, I have witnessed the departure 
of Bridger Mitchell's Advanced CP/M column and was 
disappointed to see nothing further along the lines of the 
article on available S-100 boards. The increasing focus on Z- 
System and embedded controllers reminds me all too much 
of MicroC's abandonment of "us poor CP/M'ers," who were 
grateful for even such simple things as current vendor 
listings. 

See Reader, page 52 
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PMATE/ZMATE MACROS 

5. Downloading Earlier Columns and A Sort Macro 



By Clif Kinne 



Listing 1. 

The basic Sort Macro. 
' ;Sort 



Since each of these columns presumes that the reader has 
access to preceding columns of the series, new subscribers 
are at a severe disadvantage. To alleviate this inconvenience, 
I shall post each column to Jay Sage's ZNode BBS a couple of 
months after you receive it in the mail. This delay will allow 
me to incorporate any correction and clarification that ap- 
pears needed. (Those who have worked their way through 
earlier columns know that I need some such escape valve.) 

Downloading Columns 

As of now there are just two files to be downloaded: 
PZMCOLS.ZIP: PMZMCOLS, an acronym for PMATE/ 
ZMATE Columns, is a "zip file" library of 4 files,- one for 
each of the first 4 columns: 
PZMCOLOl.RVl 
PZMCOL02.RV1 
PZMCOL03.RV1 
PZMCOL04.RV1 
The extension, RVl, indicates that the file has been revised 
once since it appeared in TCJ. PZMCOLS.ZIP is about 32 
kilobytes long, whereas the individual file lengths before 
compression toted about 82 kilobytes. 

PZMACSMAT: This is a file of all macros presented in the 
first four columns, each in executable form without com- 
ments. Since, in this form, they use relatively few bytes, they 
are not compressed. This file may be downloaded and indi- 
vidual macros put to immediate use with a minimum of tai- 
loring to your system and taste. 

The downloading process. 

Jay Sage's Z-Node BBS is at (617) 965-3552. Although this 
BBS caters to the Z-System and CP/M, the files are equally 
accessible to DOS. 

If you are running on CP/M or the Z-Sysfem, you will 
need UNZIP.COM to decompress the files. If you don't have 
it, you should get it. Jay has it on the Z-Node. It is in the 
library file, UNZIP15.LBR, whose members are crunched, so 
you will need UNCR.COM also. 

If you are running DOS, you will want PKUNZIP.EXE, 
which is in the self-unzipping library file, PKZ110.EXE, 
which, in turn, is available on most DOS BBS's. 

If you do have occasion to download these files from Jay's 



Clif Kinne is a retired computer designer. He cut his teeth on vacuum tube and 
acoustic delay line machines in the fifties, made the transition to transistors and 
magnetic cores in the sixties, left the field to his children in the seventies, and tried, 
vainly, to catch back up with them in the eighties. He can be reached by voice at 617- 
U^9055, or via a message on Jay's BBS, 617-965-7259. His address is 159 Dedham 
Ave., Needham, MA 01191 



Z-Node, please take the occasion to leave me a brief message. 
If nothing else, what version of PMATE are you running: 
ZMATE, PCMATE, MATE, or more than one? 

A SORT MACRO. 

Eight years ago this August, Lifelines published a macro 
that prepares a sorted, columnized disk directory. The sort 
part of the macro was submitted by Ron Finley of Harley, 
Oregon. Over the years I have greatly embellished and re- 



82 byte* 



FUNCTIONAL SPECIFICATION: 



Sorts B column (unsorted list, UL) of text items in 
one buffer into alphabetical order in a second 
buffer (sorted list, SL). 

The inner loop moves the SL cursor successively 
closer to the alphabetical target for the next item 
in the UL, each move being half the distance of the 
preceding, so that, on the last move of 1 line, it 
winds up just above or just below where it should 
be. 

The outer loop corrects that 1-line uncerttdnty as 
necessary before going for the next Item In the UL. 

VARIABLES USED: VO, the no. of items in SL. 

V3, the no. of lines moved on the 
current pass throught the inner loop. V3 is 
cut essentially in half after each pass. 



BUFFERS USED: 



SUBROUTINES: 
."R 
.*S 



B4 holds the unsorted list, UL. 
B2 holds the sorted list, SL. 



Restore 
SaveEnv 



USING! 
."G 
."G 



GoBack 
GoBack 



fined that DIR macro, but never modified the sort part. Now, 
thinking about offering them in this column, I thought I 
might spread them over several issues and start with the sort 
macro in this issue. 

When I went over the macro with some care, it seemed to 
be difficult to justify some of the tortu- 
ous steps taken to achieve its flawless 
performance. So I asked myself what I 
should do if starting from scratch. The 
end result is the macro depicted in 
Listing 1. This consumes 82 bytes, com- 
pared to 145 bytes in the original. It 
seems to work as flawlessly as the 



The Computer Journal / #52 



51 



original, and most of the steps I find to be quite plaiisible. 
I hope you do. The one exception is on line 14, the increment- 
ing of V3 before dividing by 2. 1 can only justify this empiri- 
cally. Maybe one of you can tell us how we could have an- 
ticipated that this was an appropriate or necessary step. 

On my 12 Mhz AT, this seems to take a second for every 
16 items in the unsorted list. This is not terribly fast, but is 
very acceptable for an average 50- to 60-item directory. On 
my 4 Mhz CP/M machine, it is 5 or 10 times slower. In 
neither case, did I recreate the directory every time I dis- 



; VSmSBt 


Th* unaortad Hat mat be In B4 tffaan thla 


} 


la eallad. Than It Bay b« callad frcm any 


? 


buffar. 


; CODE! 




.'S 


;Sava the anvlronmant . 1 


ovo 


;Clear VO (No. of Itooa in SL). 2 


B2K 


;Cle«r daatlnatlon buffar, B2. 3 


[ 


; Begin outer loop through UL. 4 


B4E 


;Go to UL. 5 


A 


;To t<^ . S 


«T-0_ 


;Tknnlnate if UL ia eapty. 7 


B2H 


;Move flrat item in UL to SL. 8 


VAO 


;Incranient no. of itama in SL. 9 


B2E 


;Go to SL. 10 


A 


;To t<^. 11 


(0V3 


; Initialize V3 to the no. of items in SL.12 


[ 


; Begin loop to put top item of UL in ita 13 




; alphabetical place in SL. 


«3+l/2V3 


; Increment previoua V3, then halve it. 14 


«H*A84$<0 


;IF item at curaor < top item in UL, 15 


{«3L 


• THEN move down. IS 


H-«3L) 


; EI^B move up; 17 


«3=1 


;IF V3 ia 1 at thia point, you are done. 18 


J 


;ELSE loop again. 19 


«H'A«45<0 


;IF item at curaor < item in UL, 20 


<I.) 


•THEN move down (to correct uncertainty) .21 


1 


22 


.'R 


;Reatore the enviromnsnt . 23 


B2E 


; Return to SL. Thia atep ia optional. 24 



played it. Instead, I saved it to disk and simply redisplayed it 
most of the times. In fact, with a fairly large directory in CP/ 
M, I often made a few patches by hand before creating a new 
one. 

For purposes of calling this in future columns, I shall have 
to give this a name, and shall simply use the one I have been 
using for years, namely, .'. 

Speedier sorting of a partially sorted file. 

Having gone this far, I worked out a modification that 
cuts the time to 40% if the UL is mostly sorted with a few 
random additions at the end of the list. So if you are using a 
DIR sorting utility, the macro will take advantage the pre- 
sorting. My deadline is upon me, so I shall simply make List- 
ing 2 the code for the lines of Listing 1 which are changed. 

The first line is line 11 from Listing 1, with the preceding 
semicolon to indicate that it is to be omitted. It is replaced by 
the following Unes, 11a, lib, and lie. The only other change 
is the addition of line 21a following line 21. 

As you can see, the new code simply checks first to see if 
the next UL item belongs at the bottom of SL. If it does, the 
inner loop is never entered. Otherwise, the inner loop code is 
executed exactly as in Listing 1. 

I wonder how many hours I would have saved if I had 
taken the time to work these things out 8 years ago. On 
second thought, I'm happier not knowing.© 



Listing 2. 




Code modifications to Liating 1 to speed sorting a partly | 


presorted list. 




; A 


;To top. (Remove original line 11} 


Z-L 


;MoyB to last item in SL. 11a 


(H''A«4$>0 


;IP item at cursor > top item in UL, lib 


< 


;IKEN execute steps 12-21 of Liating 1. lie 


HI.} 


•ELSE move to line below last item. 21a 


] 


;and return to start of outer loop 22 




; to put top item in UL here. 



Reader, from page 50 

I plan to build an S-100 board containing a real-time clock 

and work extensively with BDS C and Aztec C under CDOS. 

If articles on either of these topics would interest you, please 

let me know. 

J.J.G. Lexington MA 

We have been working more with embedded control topics as 
they have proven quite popular with the readers. Please note, how- 
ever, that 1 added nearly 30 pages to provide room for the new 
material without denying our roots, the CP/M'er. I am as con- 
cerned about abandoning our charter as anyone. For the record, we 
did not drop Bridger Mitchell. He has been very involved in his 
professional work and has promised to return when he can. I look 
forward to his next article. 

There are two things needed to assure support from any maga- 
zine: articles to publish and readers to buy the result. We have the 
readers (can always use more!) and I am interested in the articles 
you suggest. Frankly, I am rather curious why the authors and 
readers of the old S-100 Buss haven't looked this way. 

Sometimes a publisher sees greener pastures and moves beyond 
where the readers want to be. Let me know if I do this to you.— Ed. 



motor driving an AC generator, preferably with a big fly- 
wheel to smooth over hiccoughs? 

A.S.M. Bois-Colombes, France 

No, Mr. Laidley's article in issue 49 addressed two issues. He 
takes issue with using the ground plane to absorb surges as it is 
poorly isolated from signal ground in most systems. This would 
divert high energy away from the power supply, a relatively cheap 
and robust unit, and toward the TTL-level ports which are much 
more expensive and delicate. He also has concern with using 
MOVs in power protection and gives two principle reasons: An 
MOV breaks down a little at a time with every surge it absorbs, 
yet never warns that its protection is failing, and MOVs are sub- 
ject to thermal runaway. Layman's talk for this is "catching on 
fire." 

Implementing Mr. Laidley's recommendations involves using 
devices other than MOVs and avoiding use of the ground plane. 
His firm. Zero Surge of Bernardsville NJ, sells units that meet 
these criteria. The devices are neither cheap nor trivial (they cost 
about $200) but from my experience so far, they are effective. After 
losing issue 49 to a power surge (the hard disk FAT was 
scrambled), I got one of the units for Amanda, the typesetter. — Ed. 



Is W.H. Laidley suggesting, indirectly, that real power 
protection is only available via a rotary converter, i.e. an AC 



You have a great magazine. I've been playing with com- 

See Reader, page 57 
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A Home Heating & Lighting Controller, Part 3 

The Computer Hardware 

By Jay Sage 



In the two previous installments on the embedded cxjn- 
troUer that runs the electrical and heating systems in my 
house, I described first the history behind its development 
and the control strategy it applies to managing the heating 
system and then the electrical interface between the controller 
and the 120 V electrical system. Since TCJ is, after all, a 
magazine about computers, it seems high time that I talk 
about the controller itself, and that is what I will do now. 

There is no sense going into the full schematics of the 
circuit. This controller was desigr\ed and built ten years ago, 
and integrated circuit technology has advanced tremen- 
dously since that time. Besides, to be completely honest, 1 
cannot find a full set of up-to-date schematics. Quite a few 

It is interesting from an historical 

perspective to see how such a controller 

was implemented ten years ago. 

changes were introduced along the way, and their documen- 
tation is embarrassingly sketchy. In addition, after all these 
years, I no longer remember in detail how each part of the 
circuit was intended to function. 

The above notwithstanding, my main reason for not going 
into all the details is that, were I going to implement the 
functionality of this controller today, I would not use the 
same circuit design. Nevertheless, there are some useful 
things I can say about the design that, 1 think, still apply 
today. It is also interesting perhaps from an historical per- 
spective to see how such a controller was implemented ten 
years ago. 

Overall Description of thie Hardware 
Most of the controller is housed in a small wooden box (a 
previous hobby was woodworking) mounted on the wall of 
our hallway. Figure I is a drawing that I made for a talk 
presented to the Lincoln Laboratory computer club just after 
I joined the lab in 1982. The box is about 9 inches high and 
7.5 inches wide. It is open on the bottom, where a reset but- 
ton and a power switch can be accessed by reaching under 
the box. The top is also open, but a metal grill is installed to 
prevent objects from falling in. This arrangement provides 
excellent cooling! 

The operator provides input to the controller via a hexa- 
decimal keypad. Numbers are entered directly, while 
functions are invoked by holding down a small pushbutton 
switch in the lower right comer while a number key is 
pressed. The pushbutton switch acts, if you will, as a shift 
key. 

Information from the controller to the operator is pro- 



vided by a 16-digit 7-segment LED display. This unit was 
intended to display numbers in calculator applications, but 
with some ingenuity 1 was able to generate reasonable ap- 
proximations to many letters as well. In Figure 1, for ex- 
ample, the word "ALL" is displayed. Since some letters cem- 
not be formed (e.g., G, J, K, M, and T), a lot of thought had to 
go into devising appropriate display messages! 

Inside the box are two boards with the main computer 
circuitry. The first board was to contain the actual computer, 
while the second board would take care of analog signal 
conditioning and analog-to-digital conversion. Later, some 
additions to the main computer overflowed onto the second 
board as well. 

Wirewrap sockets installed in prototyping "perf" boards 
were used for mounting all components, both integrated cir- 
cuits and passive devices (mounted in carriers). A Vector Slit- 
n-Wrap tool was used to wirewrap the circuits. This tool 
really expedites such work because it slits the special wire as 
it wraps it onto the wirewrapping posts. The wire is cut after 
it is wrapped, and one can daisy-chain the connections when 
lots of pins are bussed together, as happens often in com- 
puter circuits. 

Some additional hardware is mounted near the ceiling in 
the basement below the control panel. The power supply, 
which we will describe in more detail later, is there. So is the 
board with the relay drivers that we described last time. All 

When one anticipates high volume production, 

one avoids costly parts, even at the expense of 

more complicated designs and software. 

the high-frequency circuitry is on the boards in the control 
panel, but the low-frequency and interface circuitry was kept 
out of the control panel to minimize its size and the number 
of wires that would have to go to and from it. 

The General Design Philosophy 
Before delving into the specifics of the circuits, I would 
like to say something about the general approach I took with j- 
the design. When cost is an issue — as when one anticipates 
high volume production — one tries to avoid costly parts, 
even at the expense of more complicated designs and, espe- 
cially, more complicated software. Since I anticipated build- 
ing only one of these controllers and since I wanted to spend 
my programming time on the functional software and not on 
low-level interface issues, whenever possible I chose high- 
level chips that performed low-level tasks in the hardware. 
Spending $20 on a fancy new IC was better than spending 
two weeks writing and debugging software. There will be 
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several examples of this discussed below. 
Some Circuit Details 

The CPU 

A highly abstracted schematic of the mciin bus of the 
controller is showr\ in Figure 2. The controller was de- 
signed around the state of the art CPU at the time, the 
Intel 8085. By multiplexing its data and address signals 
onto the same pins, the 8085 freed up enough pins to 
implement additioi\al I/O functioiw on the chip. Among 
these are a single-bit input port and a single-bit output 
port. These can be used to implement a bidirectional se- 
rial interface. I made no use of them, however. 

More importantly, the 8085 contains an integral pri- 
oritized interrupt controller and four vectored interrupt 
inputs ('vectored' because they force execution of spe- 
cific code addresses and do not require an external con- 
troller to jam instructions onto the bus as with the stan- 
dard interrupt input, also present on the chip). These I 
used to great advantage. 

One interrupt line is called TRAP and is non-mas- 
kable (always active). Three maskable interrupt pins — 
named RST5.5, RST6.5, and RST7.5 — are controlled by a 
special CPU register via 8085-specific opcodes: SIM (Set 
Interrupt Mask) and RIM (Read Interrupt Mask). These 
interrupts generate calls to locations in the base page of 
memory, just like the standard RST (Restart) opcodes. 
The addresses called are midway between those called 
by the RST instructions — hence the names. 

To facilitate the design of very small controllers, Intel 
provided a whole family of chips designed to interface 
easily to the 8085. These chips include on-chip circuitry to 
demux the data and address buses. I used several chips from 
this family, but I also used conventional microprocessor bus 
ICs. Thus I had to provide external bus demuxing circuitry. 

Memory 

First, the computer obviously needed memory. This took 
two forms in the controller: RAM and ROM. The RAM was 
provided by the 8155 multifunction comparuon chip to the 
8085. Within its 40-pin package, the 8155 provides 256 bytes 
of RAM along with three parallel I/O ports (a total of 22 
bits), and a counter/ timer. Two of these chips were used. 
One counter counts the output from a 60 Hz timekeeper cir- 
cuit and produces a pulse each second. This signal is routed 
to the RST7.5 interrupt, where it irutiates the main computa- 
tion cycle performed by the controller. 

The output of the one-second timer drives the counter in 
the second 8155. 1 can't remember what I intended to use that 
counter for. In my original schematic, it is shown coimected 
to the RST6.5 interrupt, but there is no code for that interrupt 
(and presumably the line is not cotmected). 

Only a few of the parallel port lines are used, and one 
8155 chip would have been enough. The second one was 
included mainly for the additional RAM. The principal use of 
the parallel port lines is to control the relay drivers. As dis- 
cussed last time, this requires six lines. One other line seems 
to have been used as a direct inhibit (blanking) on the display 
(I don't remember why). 

In a way I am amazed that I thought that a mere 512 bytes 
of RAM would be enough for the entire controller (and, just 
think, today they say that 4,000,000 bytes will barely get you 



Figure I. 
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by under Windows!). Later I decided that I really wanted 
more RAM so that the controller could log envirorunental 
data (it was that data that revealed to me how incredibly 
accurately the controller was following the programmed 
temperature profiles — much better than my theory had pre- 
dicted). 

I added four 8185 1 kB static RAM chips. These chips were 
developed as part of the 8085 family and included the bus 
interface. When I first built the controller they cost something 
like $50 each, and that was more than I was willing to pay. 
Had I included even one of them from the beginning, I 
would have used only a single 8155. 

In the early 1980s, EPROMs were still very expensive. The 
8755, an EPROM dual to the 8155 RAM, was unthinkably 
expensive at the time. Even the state-of-the-art 2716 2k-by-8 
EPROMs cost more than $50 (today they are, I believe, well 
under $5), so I selected the smaller 2758. These were, it was 
said, 2716s in which one of the two Ik banks was defective, 
leaving a lk-by-8 memory. Ironically, as IC production tech- 
nology improved, the yield on 2716s became so high that 
there were few defective chips from which to make 2758s, 
and the latter actually became more expensive than full 
2716s! Just in case my program code eventually grew to more 
then 1 kB, I included a second ROM socket. Today the con- 
troller has both sockets filled with 2732 4k-by-8 EPROMS! 
The general rule seems to be that one NEVER has enough 
memory. 

Keyboard and Display 

Desigrung the logic to handle the hex keypad and LED 
display would have been a considerable task were it not for 
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the Intel 8279 keyboard /display controller chip. This chip 
had everything I needed. 

The keypad presented no challenge to the 8279, which was 
designed to scan a full alphanumeric keyboard. Three output 
scan lines (decoded to eight) and eight input return lines 
allow the chip to handle an 8-by-8 matrix of keys. The hex 
keypad was only 4-by-4. The 8279 also has inputs for shift 
and control keys. My pushbutton 'function' key was wired to 
the shift input. When the 8279 detects and verifies a pressed 
key, it asserts an interrupt signal, which I wired to RST5.5 
input on the 8085. 

There were actually two other input keys that I have not 
mentioned before. A GE low-voltage switch is mounted by 
each of the two main entrance doors of our house. One posi- 
tion on the switch is marked 'home', the other, 'awa/. The 
controller is capable of modifying its schedule based on 
whether we are at home or away, and these two switches are 
used to convey that information to the controller. They drive 
optical isolators, whose outputs are read by two additional 
rehim lines on the 8279. 

The LED display is handled with equal facility. While only 
three scan lines are used for the keyboard, a fourth is present 
for use with the display. When these lines are decoded, 16 
digits can be addressed, a perfect match to the display I 
chose. Eight driver lines control the seven segments of the 
digit display plus the decimal point. 

Analog-to-Dlgltal Conversion 

The last major functional block of the controller is the 
analog signal processing unit. For the A/D converter, I again 
opted for a sophisticated IC that would handle as much of 
the work as possible. The National Semiconductor ADC0816 
Wcis the state-of-the-art chip at the time. It supports 16 analog 
channels and jjerforms successive-approximation ratiometric 
conversions in 100 microseconds. ('Ratiometric' means that 
values are scaled to a reference signal, for which I used the 
power supply that biases the temperature-sensing thermis- 
tacs. This makes the results independent of that supply volt- 
age.) 

The ADC0816 also includes a full microprocessor inter- 
face, so that it could be accessed essentially like a RAM chip. 
By writing to the chip, the charmel could be selected and a 
conversion initiated. The result is obtained by reading from 
the chip. When a conversion is complete, the ADC0816 as- 
serts a signal on a control line. This could be used to initiate 
an interrupt, but, since the controller had nothing else to do 
in the meantime, it was easier to execute a software delay 
loop after starting a conversion. 

The Real-Time Clock 

The above discussion covers all of the circuitry on the 
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main boards in the control panel. I would now like to de- 
scribe two of the additional circuits mounted remotely: the 
real-time clock and the uninterruptible power supply. 

As I mentioned earlier, the time is derived by applying a 
60 Hz signal to the counter in one of the 8155 ICs. This 60 Hz 
signal can come from one of two sources. 

The main source is the 60 Hz line. The electric compemy 
controls this frequency very ceuefuUy. It appears, in fact, that 
when the frequency is low for some period of time, it is later 
raised slighter until to total number of cycles is correct. This 
is why electric clocks keep such accurate time, unless there is 
a power failure. 

I took the AC from the secondary of a bell transformer 
and applied it to the input of an optical isolator. The LED in 
the isolator serves as a rectifier, so that the output on the 
other side of the isolator is a 60 Hz pulse train. Two steps are 
then taken to make sure that this signal is clean (does not 
contain many spikes at the transition threshold). First, the 
signal is passed through a Schmitt trigger, and then it drives 
a nonretriggerable monostable set to produce a 5 ms pulse. 
This signal serves as one input to a two-input multiplexer. 

The other clock signal, which is applied to the other input 
of the mux, comes from a crystal-stabilized clock chip. Using 
a crystal at the color subcarrier frequency of a television sig- 
nal, this chip produces a 60 Hz pulse train. This signal, how- 
ever, is far less accurate than the one derived from the AC 
line. 

How do we determine which signal to use? Well, the sig- 
nal derived from the AC line also goes to a retriggerable 
monostable which is adjusted to a 20 to 25 ms pulse. So long 
as the AC power is present, pulses come at intervals of 16.7 
ms, and this monostable is constantly triggered. As soon as a 
single cycle of the 60 Hz AC line is missed, however, this 
output drops. This does two things. First, it causes the multi- 
plexer to send the crystal timebase signal to the 8155 counter. 
It also serves as a power-fail signal and is connected to the 
TRAP interrupt. When we discuss the controller's software 
next time, we will describe how the controller uses the 
knowledge that the power has failed. 

The UPS 

I don't think I really have to say that maintaining power 
to the controller is of the utmost necessity. Thus, an uninter- 
ruptible power supply was essential. 

Basically, the controller runs off a 5 amp-hour, nominally 
8 V Gates sealed lead-acid battery. This uses similar technol- 
ogy to that in a car battery, but the dangerous gases are not 
allowed to escape from the cell. The second computer board 
contains a regulator IC that drops the voltage to an accurate 5 
V. The battery was designed to keep the controller rurming 
for at least 8 hours. 

Meemwhile, so long as the AC power is available, the bat- 
tery is charged by a power supply. A small transformer, a 
bridge rectifier chip, and an adjustable voltage regulator IC 
generate a roughly 102 V signal. This signal passes through a 
diode on its way to the battery so that there is no chance that 
the battery could discharge through the power supply during 
a power failure. The variable regulator is adjusted to produce 
a voltage of 9.2 V on the battery side of the diode, the level 
that Gates recommends for continuous charging. 

That covers what I intend to say about the controller cir- 
cuitry and hardware. Next time we will take a look at the 
software. • 
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Assembler Programming, from page 24 

SCRLD updates the value field in each screen image for 
each configurable item in the target configuration page, then 
stores a copy of the first Menu Data Structure (MDS) in a 
working buffer (MENLST:) in ZCNFG. 

A few details have been omitted in that defirution! The 
CFG file was originally assembled, then linked to make a 
binary image file. That means that the addresses in the file 
start at some value which we will call ORGCFG. You may be 
sure it is not now loaded at that address! Therefore, the 
pointers in MDS are all wrong by a constant which is the 
difference between (OVRLAY) and ORGCFG. This difference 
is called a relocation constant; it is calculated in SCRLD 
stored for future use at RELOCC:. The relocation constant is 



that input is converted to binary, stored in the target configu- 
ration page, then converted to screen format and transferred 
to the screen image. The addresses for these conversion rou- 
tines are stored in a table (FNTBLE:). There two symbols as- 
sociated with each function in the table. The first symbol is 
IN_FNx, a keyboard input and conversion function; the sec- 
ond is LD_FNx, which loads a screen image field from a 
configuration item, 'x' is a function number. See Listing 3. 
ZCNFG is finally ready to go to work for you! 

THE MAIN PROGRAM 

The core of ZCNFG is only about 20 lines of code! It starts 
at the label SETOPT: and ends with the instruction ]R 
SETOIT. This looks like an ir\finite loop! Here is the se- 
quence of events in this code: 



Listing 5. 



PROGRAM EXIT 



;Noiiiial exit after changes are made and need to be 
; saved. Assumes that tgtbuf has been updated before 
;writing the first block back to the file. 



BXIT: 



EXITl: 



LD 
OR 
JR 
U> 
LO 

LD 

LD 

LO 

CALL 

LD 

CALL 

EX 

LD 

CAIX 

EX 

CALL 

ID 

CALL 

CALL 



A, (Z3INST) 

A ;allow Z3 installation? 

Z, EXITl ;no, if logical false 

HL, (Z3ENV) ; install current ENV address 

( TGTBUF+Z 3EOFF ) , HL 



A, (FCB_CR) 

(pcbk5ec),a 

DE, TGTBUF 

SETDMA 

DE.FCB 

VIRREC 

DE.HL 

DE,TGTBUF+80H 

SETDHA 

DE.HL 

MRREC 

A, (TGTDU) 

CLSTTL 

Z3CLS 



;set current record for writing 
; back the configuration block 



;fcb pointer 

; write first 128 byte record 

; preserve fcb pointer 



; write second record 

; close the file 
; clear the screen 



;IlBXe to exit without saving current changes. This is 
;effectively an abort. Assumes that the saved stack pointer 
;polnt8 to a safe execution address. This is the case when 
;tbe program is executed as a nomal .ccm file. 
QUIT; 



ID 


A,(Z3MSGF) 




OR 


A 


;if ZCPR3 present, 


CALL 


NZ,DIHIT 


; deinit terminal 


U> 


SP, (STACK) 


; restore callers stack 


RET 




; return to CCP 



added to any address from the CFG file before it is used. The 
MDS was relocated during the copy operation. 

Recall that there is an MDS for each menu in the CFG file. 
Each MDS is part of a doubly linked set of records. The first 
two words in each MDS are pointers to the preceding and 
following MDS in the list. Each MDS also contains pointers to 
its related SCREEN IMAGE, CASE TABLE, and HELP 
SCREEN. These pointers allow ZCNFG to locate and work 
with any data in the CFG file. 

There is another detail whose omission you may have no- 
ticed. The items in the target configuration block are all bi- 
nary, and must be converted to any one of a number of 
ASCII formats in the screen image. One of the entries in each 
CASE TABLE reccard specifies the conversion that must be 
made. So part of the update process mentioned above is to 
call the appropriate conversion routine. User input during 
configuration is always ASCII (that's how keyboards work!); 



1. display the current screen image (menu) 

2. display the ZCNFG commands and a user 
prompt 

3. get and display user input (menu selection) 

4. CALL MCASE to perform the action implied by 
the user input 

5. If MCASE returns an error flag go to 3, else start 
again at step 1. 

The secret is in step 4, the call to MCASE, which: 

1. searches the current case table for an item which 
matches that input by the user. If found, jumps to the ap- 
propriate service routine from the list of routine ad- 
dresses in the table labeled FNTBLE: If not found, con- 
tinue at step 2. 

2. searches the case table buUt into ZCNFG. This table 
is located at label CTLCSO:. These are for the functions 
shown at the bottom ol figure 1, "ZCNFG INSTALLA- 
TION CONTROL". Notice that one of the functions is 
to exit the program, with or without saving changes. 
As in step 2, jump to the appropriate service routine or 
if no match for user input is found, continue at 3. 

3. Returns an error flag. 
In all cases except those involving exit, a return to 

the caller of MCASE occurs. Refer to Listing 4. 

The Program Exit 
There are two ways to leave ZCNFG: with and with- 
out saving changes. The routine at EXIT: writes the cur- 
rent configuration page back into the target file. This 
page contains any updates made during the ZCNFG session. 
After the write, the target file is closed, the screen is cleared 
and the QUIT: routine takes over. QUIT deinitializes the ter- 
mirwl (if required), and performs one final critical action. It 
restores the Stack Pointer to that of the CCP and does a RET 
ii\struction for a silent return to the CCP. ZCNFG is fiiushed. 
See Listing 5. 



Subroutines 
You will observe that most of the work done by ZCNFG is 
done in calls to subroutines. And the subroutines call more 
subroutines! Those that are really uiuque to the flow of logic 
in the program are a part of the SUBROUTINE section near 
the end of the source file. Lower level subroutines which are 
simple functions are in a separate file, CFGSUBS.Z80. Still 
other functions are commonly used and come from such 
standard rel libraries as Z3LIB, VLIB, and SYSLIB. ZCNFG 
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also uses a special rel library, CFGLIB, which contains 
modified filespec scanning routines from ZCPR3. 

Some subroutines are only called once. Why not just in- 
clude them in-line? One reason is to keep main sections of 
code short, preferably less than one page long. Intelligent 
comments are required to keep the reader (you, a year or two 
from now) from getting lost. A second reason is illustrated 
by the MCASE routine; it contains some very tricky code that 
would become even more treacherous as in-line code. De- 
bugging and maintenance are usually easier for a subroutine 
than for equivalent in-lirw code. 

Data Section 

Iiutialized data comprises DB or DW statements whose 
value is determined during assembly and lirvking. Uninitial- 
ized data comprises DS statements and may also result from 
ORG statements. An area of uninitialized data cannot gener- 
ally be depended on to be filled with any particular value; 
this is data space to be used during program execution. The 
buffer in which the configuration page is stored is a typical 
example. 

The program structure in figure 2 implies that uninitial- 
ized data should be last in the program. Linkers like ZML 
will produce a COM file which does not include DS areas at 
the end of the code image. That makes for a shorter file to 



store and load. But beware! The only way to be really sure 
that this really happens is to declare DSEG for all DS areas 
(and be sure to switch back to CSEG for non-DS areas). ZMLs 
default linking strategy is to place all DSEG after CSEG in 
the COM file; that will be last if no COMMON segments 
have been declared. In such a case, terminal DS areas will not 
be included in the COM file. That is also why you cannot 
depend on the values initially present in DS areas; they are 
undefined unless you have filled memory with a known 
value before loading the COM file for execution! If this all 
seems obscure, just remember to habitually follow the DS last 
strategy. It will eventually make sense. 

Auf Wiedersehen 

We have reviewed the overall organization of a typical AL 
program, using ZCNFG as an (imperfect) example. Along 
the way, some of the strategy in ZCNFG has been discussed. 
The intention has been to expand on rather than repeat the 
materia] in ZCNFG.WS. There you will find rigorous defini- 
tions of the data structures used in CFG files. The routines in 
ZCNFG operate on those data structures. In the next article 
we'll discuss some of the routines in more detail: how appar- 
ently uncalled subroutines are used, indirect calls, menu 
management, and the use of pointers. Begins to sound like 
'C, doesn't it? • 



Reader, from page 52 

puters ever since I read the article in Popular Electronics on 
how to build the Altair. Your magazine is full of the same 
type of people that were doing things in and with computers 
right after that. Unlike many of the magazines that now pub- 
lish only IBM PC fluff, you print articles about hardware and 
software (what computers are all about). 

I've just picked up 3 Cromemco S-100 systems and plan to 
use them for a CAD/ CI M in my home workshop, if I ever 
get the time. By day, I'm a Tool and Die maker and at night 
build motors and play with computers. 

S.B. Phelan CA 

Thanks for the compliments, S.B.! Yes, TCJ is filled with the 
right kind of people, and that includes you. The difference between 
the TCJ reader and most others is that our folk prefer to roll their 
own solutions to a problem than to pull out the checkbook for 
someone else's fix. 

Care to tell us more about that project you hive lined up for the 
Cromemco's? — Ed. 



Hacker's query: How can I read a sector of a Commodore 
1581 disk into a buffer using an AT clone's 1.44MB drive? 
The shareware program ANADISK usually works, but it 
doesn't do what I want to do. INT 13h doesn't seem to work. 

].R. San Franciso CA 

Bill Woodall, our technical advisor for MS-DOS, says that he 
doubts you can reliably read this disk using the standard AT 
floppy controller. The COPY-II PC Deluxe Option Board from 
Central Point Software allows for reading GCR formatted disks 
such as are used on Commodores, Apple ll's and Macintoshes and 
comes with the appropriate utilities. — Ed. 



I have two computers at home: a "stock" Morrow MD-3 
and a Kaypro 2X with NZCOM and ZSDOS, Advent Tur- 
boROM, 1MB RAM disk, 32MB hard disk and one of those 
rare Microsphere Color Graphics boards. 



Since we lost Profiles and Micro Cornucopia, you guys are 
about all that's left supporting CP/M and the Z-System. 
Long live the Z-System! 

J.W. West Lafayette IN 

1 and my Ampro ISO's agree with you wholeheartedly. — Ed. 



The idea of promoting TCJ within user groups is very 
good: the articles lend themselves as very good subjects for 
discussion during meetings and provide a common back- 
ground to everyone willing to participate. 

L.V.H. Mill Creek, WA 

1 ama big proponent of user groups but have found that most 

rely on a few individuals for all their advanced topics. Using a 

journal such as TCJ can fuel the discussions without overtaxing 

the group "gurus. " I am happy your group is using the journal for 

just this purpose. — Ed. 

See Reader, page 60 



Computer Comer, from page 58 

program (use a flag in the file header structure to tell the 
difference). If I went to MINIX directory then, it would forget 
all the DOS words and load MINIX words. Then I could run 
MINIX programs, or Forth programs as before. 

In either case the MINIX or DOS programs would have to 
be compiled to run on my hardware of choice, but the actual 
operating system would be a Forth kernel capable of running 
the Forth source code directly! 

Time Out 

I just rem out of space and ideas. Actually I have a few 
more thoughts on a UOS but am keeping those a closely 
guarded secret. I'll be wailing to see how much trouble I get 
into for my open letter. How about you Z80 users, like to see 
a UOS that you could use as well???* 
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Computer Comer, from page 64 

the operating system. We have seem a new version of 0S2 
offered up from the DOS camp as a contender for the tittle of 
Universal Operating System as w^ell. 

The C people to me have one disadvantage which Forth 
solves. All the new contenders are based on ports to new 
hardware and will be very large programs. For my Z80 or 
my 512K 68K system, none of those ports will work. MINIX 
on a Z80, or a Z180 might be possible but I have my doubts. 
This is where 1 feel Forth still has the only chance. Let me 
explain. 

Stack Based Virtual Machine 
In Forth the concept is creating a stack based virtual 
machii\e that is the same no matter what hardware you are 

The problem with Forth for some time has 

been the lack of a specific standard for 

people to follow. 

on (a hardware machine done in software). The actual 
operations performed by the hardware to do the desired 
operation is of no concern to the programmer. I know that if 
I put 2 and then 4 on the stack with a plus sign and a period 
it will print 6 on the screen. I can do that on any hardware 
port and get the same answer as long as I do not exceed the 
artificial hardware limits. Artificial I say because the designer 
or programmer sets the data size based on hardware and 
standards. 

The problem with Forth for some time has been the lack of 
a specific standard for people to follow. The problem with 
any operating system is standards. The problem with the 
computer industry has been creating standards before a 
product has died a slow death. In reality all big selling com- 
puter systems are not based on standards but what got to 
market first and also gained the market shares needed to 
become a standard. MSDOS is an example of a late comer 
that used a big name and then by default became a standard. 

The first product that actually can get some backing and is 
truly portable to all types of hardware will be the next stan- 
dard. That means providing for the users something that can 
not be gotten anywhere else. Remember the first rule of mar- 
keting: provide something to the buyer that they can not get 
elsewhere. A marketing proverb also says the market will not 
wait for you ( he who hesitates is lost). 

My Product 
It is at this point 1 give you my open letter to Forth system 
manufactures. It goes like this: 

Dear Forth Manufacturer 
RE:Universal Operating System (UOS) 

I have been reading Forth Dimensions lately and have got 
very tired of seeing f>eople write how they are tired of learn- 
ing Forth and not being able to use it commercially. The 
answer I feel is that you manufacturers have let down us 
users. Many of us went to Forth as a means of bridging 
hardware systems by doing our programming in what we 
hoped would become a universal language (non-hardware 
specific). 

I am pleased to see the work going on in getting an ANSI 



Forth standard. The standard will help but it is taking so long 
that most Forth programmers will have jumped ship by the 
time it is finished and adopted by you manufacturers. What 
we need is for one you who, who already has the products, 
to produce a Universal Operating System (UOS). Let me ex- 
plain. 

My idea of an UOS would be along the lines of early 
BASIC and the compiled run time module. A number of 
these run time products would be provided by you for each 
of the current and past hardware platforms. It would be a 
special version of your current kernel that provides hooks for 
programs to run on (a Forth, BIOS and DOS all combined). It 
would need a sale price of under $50. To that a vendor writes 
a program that uses your hooks and sells their (encrypted) 
Forth source code to run on top of it. A typical program 
could sell for $50 but you must remember it can run on all of 
the platforms you support. 

For a user to write programs for their own use you would 
sell them a iiser package, or ANSI Forth that is your normal 
program riding on top of your run time package. I see a $99 
price tag here with some learning Forth type of manuals. The 
professional programmer buys your $499 package which 
provides them with all the tools and information needed to 
write programs for the run time package. The source code 
gets encrypted and that utility is provided here. Now some 
users will want embedded applications and as such a sepa- 
rate ROM version of the run time package with a special 
price of course. Since none of the source has been provided 
on the internals of the run time module, special royalties and 
pricing would apply for those needing the internal source. 



The first product that actually can get some 

backing and is truly portable to all types of 

hardware will be the next standard. 



probably your current prices you now charge for a metacom- 
piler. 

With the above pricing and the ability to run programs on 
any machine directly from the source code, I can actually see 
a Forth system becoming the path to the Universal language 
and Operating System. 

Thank You, 
Bill Kibler 

Some Details 

The MINIX connection is how I might consider doing the 
run time module. In UNIX and DOS we have path like struc- 
tures which are all based on files and their disk location. In 
Forth we use vocabularies to separate groups of actions or 
words. I think these two concepts could be one. Why not 
make your means of setirching vocabularies the same as you 
would seari;h for a file? Let's go even deeper by making a 
sub-directory contain words that control how you use pro- 
grams saved as real files. 

To explain the last, let's say we have two sub-directories, 
one called DOS and one called MINIX. If I change to the DOS 
path, it would load system words that provide the standard 
DOS interface for programs. I could then run a regular DOS 
program (if my hardware supported it), or a Forth based 

See Computer Comer, page 57 
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Plu*Perfect Systems == World-Class Software 



BackGrounder ii $75 

Task-switching ZCPR34. Run 2 programs, cut/paste screen data. Use calculator, notepad, screendump, directory 
in background. CP/M 2.2 only. Upgrade licensed version for $20. 

Z-System $69.95 

The renowned Z-System command processor (ZCPR v 3.4) and companion utilities. Dynamically change memory 

use. Installs automatically 

Order Z3PLUS for CP/M Plus, or NZ-COM for CP/M 2.2. 

ZMATE $50 

New Z-System version of renowned PMATE macro editor with split-screen mode for two-window viewing of one or 
more files. Extremely powerful and versatile macro capability lets you automate repetitive or complex editing 
tasks, making it the ultimate programmer's editor. Macros can be saved for reuse and also assigned to keys. 
Editing keys can be reconfigured for personal style. Supports drive/user and named-directory file references. 
Auto-installs on Z systems. Z-80 only. Supplied with user manual and sample macro files. 

Pluperfect Writer $35 

Powerful text and program editor with EMACS-style features. Edit files up to 200K. Use up to 8 files at one time, 
with split-screen view. Short, text-oriented commands for fast touch-typing: move and delete by character, word, 
sentence, paragraph, plus rapid insert/delete/copy and search. Built-in file directory, disk change, space on disk. 
New release of our original upgrade to Perfect Writer 1 .20, now for all Z80 computers. On-disk documentation 
only. 

ZSDOS $75, for ZRDOS users just $60 

State-of-the-art operating system. Built-in file DateStamping. Fast hard-disk warmboots. Menu-guided installation. 
Enhanced time and date utilities. CP/M 2.2 only. 

DosDIsk $30 -$45 

Use MS-DOS disks without copying files. Subdirectories too. Kaypro w/TurboRom, Kaypro w/KayPLUS, MD3, 
MD11, Xerox 820-1 w/Plus 2, ON!. CI 28 w/1571 - S30. SB180 w/XBlOS - $35. Kit - $45. Kit requires assembly 
language expertise and BIOS source code. 

MULTICPY $45 

Fast format and copy 90+ 5.25" disk formats. Use disks in foreign formats. Includes DosDisk. Requires Kaypro 
w/TurboRom. 

JetFind $50 

Fastest possible text search, even in LBR, squeezed, crunched files. Also output to file or printer. Regular 
expressions. 



To order: Specify product, operating system, computer, 5 Plu'Perfect Systems 

1/4" disk format. Enclose check, adding $3 shipping ($5 '^^ 23rd St. 

foreign) + 6.5% tax in CA. Enclose invoice if upgrading Santa Monica, CA 90402 

BGii or ZRDOS. (21 3)-393-61 05 (eves.) 

BackGrounder ii ©, DosDisii ©, Z3PLUS ©, PluPerfect Writer ©, JetFind © Copyright 1986-88 by Bridger Mitchell. 



Reader, from page 57 

1 found the articles on Getting Started in Assembly Language 
very interesting. I guess it is about time I learned to use it. 

J.F. Lake Zurich IL 

Al Hawley seems to have hit on a winning topic here. It seems 
there are a number of people who having been doing programming 
in high level languages for years that have wanted a bridge to 
assembler. As the author of the ZMAC assembler, Al certainly 
knows his subject! — Ed. 



In resfionse to our brief chat on GEnie tonight, I am en- 
closing a check for a two year subscription. The article dis- 
cussing the parallel/ SCSI conversion is of particular interest 
to me. 

It certainly proved to be an enlightening 20 minutes or so. 

D.E.F. Minneapolis MM 

This letter refers to a real-time conference on GEnie in April 
where I was the guest speaker. I was asked back again in June for a 
repeat. I certainly enjoyed both conferences and it seems others did 
as well. Let me encourage readers to join in the CP/M and Forth 
SIGs on that service. 

By the way, 1 am expecting another article on adding SCSI to 
computers that lack it, but this time using a wire-wrapped daugh- 
ter board under the CPU. — Ed. 



I am using ZSDOS quite a bit and find it to be a great 
enhancement for CP/M. I note in Jay's column for issue 51 a 
list of three publications leaning to CP/M and Z-System. I 
would like to add two more. They are not quite as technical 
but more oriented toward the guy who is trying to make his 
old machine do his bidding. These are The SEBHC Journal by 
the Society of Eight-bit Heath Computerists and The Staunch 
89er. Both of these publications mention TCJ as the ultimate 
for technical information, but I have not seen them referred 
to in TCJ. 

S.R.E. Hemet, CA 

Thanks for mentioning these two publications. You are right, 
they are very good. I subscribe to one of them myself and shoidd 
send an order in for the other. Though their titles talk to Heath 
computers, they are good general-information CP/M rags. 1 recom- 
mend them both. The address for SEBHC Journal is 895 Starwick 
Drive, Ann Arbor Ml 48105. The Staunch 8/89er has an adver- 
tisement in the Marketplace page of this issue. — Ed. 



Your comment about the one company that sells postage 
meters caused me to write this letter. It just ain't so. Since we 
all know about Pitney-Bowes, I must assume you think they 
are the only postage meter company around. There is also 
Friden, and two others. 

B.C. Chicago IL 

We learn something new every day. Thanks. — Ed. 



Editor, from page 2 

I was a bit embarrassed when I published the Z-Node 
listing back in issue 50. Bob Dean's system was shown as 
down. Even though I had called and gotten through the day 
before we went to press, 1 forgot to correct his entry. So when 
Ian Cottrell was asked by Jay Sage to release the next edition, 
I volunteered to verify the US systems. 

There is a system on the US west coast that is shown in the 
RCPM listing as being a Z-Node, but which is not in the Z- 
Node list itself. I logged on, explained what we were doing 
and asked if I should show the system or not. The answer 
surprised me. 

No, the sysop said, he had dropped his affiliation to pro- 
test the commercialization of Z-System since the demise of 
Echelon. 

What? What commericialization? Let's look this over. 

Echelon was a hold-out of commercial support for Z-Sys- 
tem before closing its doors back in 1987. Though they al- 
lowed for free distribution of ZCPR source code, they 
charged for everything else. It was a company like any other, 
and needed to make a profit to survive. And while their 
policy of giving the source code away was a noble gesture, it 
also contributed to the unprofitability of the company to a 
point where it did not survive. 

Question: As Echelon charged for their products with the 
exception of ZCPR source, were they not commercializing Z- 
System? 

Question: Did it serve the public good to have the com- 
pany fail? 

Since that time, a few enterprising people have picked up 
the ball and continue to support Z-System. NZCOM, which 
replaces Z-COM (always a commercial product, by the way), 
ZSDOS, BackGrounder II are examples of their products. 
Would it be in the public interest that these products not be 
available? 



Keep in mind, while CP/M has a heritage of a strong 
public domain, this extends to utilities and a few applica- 
tions. With the exception of the original ZCPR source code, 
operating systems have never been public domain. The same 
is true of languages and assemblers. Do you believe Bill 
Gates gave away M80 and L80? Was Gary Kildall giving 
away CP/M 2.2? Have you called Digital Research lately to 
get a copy of PL/I? They'll ask for your $500 check first, as 
will Ashton Tate for dBase-lI. 

A related string of messages have been floating down the 
wire on the Internet comp.lang.forth newsgroup. A fellow 
was looking for an alternate source for F68HC11 CPUs. It 
seems he didn't care to pay $25 more for an F68HC11 than 
for a straight 68HC11. Well, let's look at this. The F68HC11 
has Forth built into it and is proprietary to New Micros. 
Essentially, you are paying $25 to New Micros for their code. 
Should we expect New Micros to work for free? Would you 
quit your job, work for free and pay the bills necessary to 
support your users? My only wonder is why New Micros 
gives you such a powerful chip so cheaply. 

Where is this tirade leading? When we cry for lack of 
support yet damn those who will stand by us, we are hypo- 
crites. If we begrudge a company sufficient income to pay its 
bills, we are calling for its failure. Most of the companies that 
support our systems, whether they be Forth or Z-System, are 
very small. Not many are getting rich at this. 

We come then to the opening question: When is the Public 
Domain not in the Public Interest? The answer: when atti- 
tudes are created that require all products be provided for 
free, thereby forcing the fmlure of any company that attempts 
to support the public. 

Thank the public domain programmer. This person is 
truly a treasure. But do not condemn someone for needing to 
support a family when you are needing his labor. Not all can 
work for free. 
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The CPU280 

A High-Performance Single-Board Computer 

By Tilmann Reh 



The CPU280 is a complete computer based on Zilog's 
high-performance Z280 CPU on a single 160 x 100 mm board 
(EviroCard). The circuit is designed to give maximum per- 
formance without unnecessary circuit expense. Since the 
Z280 is fully software compatible with the Z80, all Z80 appli- 
cation software can be run without modification. New soft- 
ware can be developed to use the much more powerful in- 
struction set of the Z280, further increasing the computer's 
performance. 

The CPU280 consists of a PCB with the CPU itself, all 
necessary memory, two serial interfaces, a real-time clock 
with non-volatile RAM, a floppy controller, and a bus inter- 
face. The circuit design is very straightforward with fully 
synchronous timing signals, which results in good operating 
stability. Since all parts are CMOS, the power requirement is 
very low: running at maximum clock speed, the whole board 
draws about 350 mA from a single 5 V supply. 

The CPU is run in 16-bit Z-bus mode, the fastest available 
bus option for the Z280. Clock frequency is up to 12.288 
MHz, with the on-board memory bus running at full clock 
speed. There are two EPROM's with 64 or 128 kB capacity on 
board, providing boot/system software. Dynamic RAM may 
be configured as 512k, IM, 2M, or 4M bytes, depending on 
the type and number of RAM chips used. All memory is 16- 
bit wide, and the dynamic RAM supports the processor's 
burst mode (reading 4 words of instructions with two mem- 
ory cycles). 

The internal serial interface of the Z280 is completed with 
external handshake signals and line drivers to build a com- 
plete RS-232C interface with hardware handshaking. Another 
serial interface chip on the board adds a second RS-232C 
interface. Both serial interfaces are fully programmable in 
data format and data rate (up to 38400 bps each), and both 
are capable of interrupt-driven operation. 

The real-time dock (RTQ supports date and time infor- 
mation required by modem operating systems. It can also 
provide periodic interrupts or an alarm interrupt at a pre- 



programmed date and time. A lithium battery maintains 
power to the RTC and to 50 bytes of RAM. This NV-RAM is 
ideal for storing setup and configuration parameters. 

The on-board floppy disk controller (FDC) is able to con- 
trol up to four drives of any type and in any combination. 
The maximum data rate is 500 kbps, which results in maxi- 
mum disk capacities of 1.44 MB (5.25 inch) and 1.76 MB (3.5 
inch) when using high-density drives. Double-density disks 
in 5.25-inch drives with fbced rotational speed of 360 rpm are 
also supported (data rate 300 kbps). Floppy I/O can be 
handled with one of the four DMA channels of the Z280. 

External 1/0 extensions are supported with an ECB-Bus 
interface. As the address decoding uses an extra I/O address 
page for the bus interface, all 256 1/0 addresses of standard 
ECB are available. The bus clock is half the memory clock 
(6.144 MHz max.), with timing signals stretched to meet the 
requirements of standard Z80-B peripherals. External inter- 
rupts are supported, in any of the Z280's interrupt modes. 
Further on-board I/O includes three LED's functioning as 
status indicators and three software- readable jumpers (i.e., 
for configuration purposes). 

There is a complete CP/M-3 (CP/M-Plus) installation 
available, using every feature of the board. Besides the 
CPU280 board and this software, you need only a disk drive 
and a CRT terminal to build a complete high-performance 
CP/M-3 workstation (performance is comparable to a Z80 
running at 15-20 MHz, depending on software). The cold- 
boot loader supports various configurations (using the NV- 
RAM) via it's setup menu. Normally, the whole operating 
system, including the command processor (CCP), is booted 
straight from the EPROM; for upgrading or testing, disk boot 
is also possible. Both the boot loader and the operating sys- 
tem support flexible disk format changes using the ' AutoFor- 
mat' feature of the BIOS. You are able to swap freely between 
many different formats. The menu-driven 'FormatManager' 
program handles format definitions and disk formatting and 
checking.© 



Who Do You Love? 

I have a custom of giving a word of thanks to those whose 
help has been instrumental in putting TCJ out. This month, 
there are three people I want to shine the spotlight on. Myla, 
Jermifer and Cathy. These three young ladies are, if you will, 
our shipping department. Myla acts as supervisor while the 
other two struggle frantically to get all the issues addressed 
and ready for the post office. What had been taking me three 
days took them one evening. Should I mention that the three 
are my daughters? No man could ask for finer children. 

Thanks, kidslPizza's on me.# 



Real programmers don't document, 
If It was hard to write, 

it should be 
hard to understand. 

— Anonymous 



^^ 
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By Bill Kibler 



I have a few topics to cover and an open letter to explain. 
It has been rather busy lately and I have been doing some 
thinking about my choices in operating systems. That think- 
ing usually gets me into trouble, but then life would be bor- 
ing without a little trouble. 

68KEForth 

I have put a ruiming version of 68K assembly based 
EForth on GEnie and it has been down loaded over ten times 
so far. I did not find any messages to me about it (or any- 
thing for that fact...) which makes me feel that no one has 
found anything wrong yet. 

It was interesting to note how it worked ok on a 68020 but 
not a 68000. All the problems were the UM/MOD or un- 
signed divide function. Everything uses this function and so 

Chuck Moore said how it made all the 

difference when he separated the return 

stack from the data stack. 

little worked until I changed it. The difference between the 
processors was in aligning the code. The 68000 must have 
longs on even boundaries, while a new feature of the 020 
does not care about even boundaries. 

It never seems to amaze me that I always learn something 
new (or forgotten from the past) when I do these ports. I had 
studied the 020 but had not really understood the difference 
between it and the 68000 until I tracked down the problem. 
We are trying to find an interrupt based bug in our 68K code 
at work and again I thought I understood interrupts. Well I 
really understand them now, and can even follow an opera- 
tion back many levels. Normally, this would not be a 
problem, but our code does some really bad stack games 
when they push parameters. 

Let me say here and now that the best way to pass data on 
stacks is to have two separate stacks. Chuck Moore (creator, 
if you will, of Forth) said how it made all the difference 
when he separated the return stack from the data stack. I 
would say that for most programmers, their programs are 
seldom so complex that separate stacks would mean little to 
them. Our programs are so multi-threaded and complex that 
it is amazing that it runs using one stack. 

Actually, there are many stacks in the program (one for 
each process running) but all data and return addresses are 
on them. A most bazaar method of passing pointer to point- 
ers on the stack has us adding to return addresses, 
calculating displacement of saved register data, offsetting 
around storage pointers, tracking the number of items 
passed, trapping if too few or too many items passed, and 



more. Before using Forth and now after using it for years, I 
always felt that data should be on a separate stack from the 
system or return stack. Working on this program has shown 
just how right a decision that was. 

Well here comes my regular lecture about macros and how 
bad they are. 1 thiidc it was a contributing factor in using such 
a bad stack method. Some person wrote a macro to do all this 
fancy stacking and un-stacking and since no one could figure 
it out they were all forced to use it. Lets see, there are 200 
files which probably use this macro 3 to 4 times in each file 
and typically there are 4 separate process stacks, with over 
$40 (64) bytes for each time it is used. That makes these stack 
very long and probably slows the overall operation down by 
30%. A simple push of the needed items, even if blank val- 
ues, would be many time faster. 

Universal DOS? 

Well I have started doing my MINIX port onto a SAGE/ 
STRIDE computer. First, let me say if anyone has done it 
already please drop me a line so I can stop. As I start moving 
on the project, I can see how it will be a learrung experience 
only. The newer version (1.5) needs more memory than my 
512K 68K machine and will have to stay at the old level (1.3). 
What I need is a smaller and more compact DOS. MINIX has 
some good ideas (well really UNIX) and that got me thinking 
(trouble time again). 

What got me into Forth and now MINIX was trying to set 
up a universal operating system. I have so many different 
systems that I wanted a single DOS that would allow me to 
use a single program (and disk format) on any of those 
systems. Forth offers that option, but most ports have no 
operating system or consist of other constraints preventing 
commonalty between systems. MINIX might give you the 
commonalty of operations between systems, but all 
programs would have to be recompiled (the C programs that 
is) before working on a different port. 1 have also seen in 

POSIX and other groups are trying to make 
just what I want to some degree. 

both systems problems caused by hardware variations 
making each port difficult with lots of special attention to 
make it work. 

If you have been following any of the computer maga- 
zines you will know that my wants are actually pretty well 
universal. POSIX and other groups are trying to make just 
what I want to some degree. The groups are basing it on C as 
their language which does have some merits and UNIX as 

See Computer Comer, page 58 
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Developer Packages 

as low as $200.00(8 $50.00 Savings) 

A New Project 

Our line of macro Cross-assemblers are easy to use and full featured, 
including conditional assembly and unlimited include files. 

Get It To Market-FAST 

Don't wait until the hardware is finished to debug your software. Our 
Simulators can test your program logic before the hardware is built. 

No Sourcel 

A minor glitch has shown up in the firmware, and you can't find the original 
source program. Our line of disassemblers can help you re-create the 
original assembly language source. 

Set To Go 

Buy Our developer package and the next time your boss says "Get to work.", 
you'll be ready for anything. 

Quality Solutions 

PseudoCorp has been providing quality solutions for microprocessor 
problems since 1985. 

BROAD RANGE OF SUPPORT 

• Currently we support the following microprocessor families (with 
more in development): 

Intel 8048 RCA 1802,05 Intel 8051 Intel 8096 

Motorola 6800 Motorola 6801 Motorola 68HC11 Motorola 6805 

Hitachi 6301 Motorola 6809 MOS Tech 6502 WDG65G02 

Rockwell 65C02 Intel 8080,85 Zilog 280 NSC 800 

Hitachi HD64180 Motorola 68000,8 Motorola 68010 Intel 80C196 

• All products require an IBM PC or compatible. 

So What Are You Waiting For? Call us: 

PseudoCorp 

Professional Development Products Group 

716Tliimble Shoals Blvd. Suite E 

Newpon News, VA 23606 

(804) 873-1947 FAX: (804)873-2154 
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William P Woodall • Software Specialist 



Custom Software Solutions for Industry: 
Industrial Controls 
Operating Systems 
Image Processing 

Custom Software Solutions for Business: 
Order Entry 

Warehouse Automation 
Inventory Control 
Wide Area Networks 

Publishing Services: 

Desktop Systems 

Books 

CEH" 



Hardware Interfacing 
Proprietary Languages 
Component Lists 



Point-of-Sale 
Accounting Systems 
Local Area Networks 
Telecommunications 



Format Conversions 
Directories 
Interactive Video 



33 North Doughty Ave, Somerville, NJ 08876 • (908) 526-5980 
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SAGE MICROSYSTEMS EAST 

Selling & Supporting the Best in 8-Bit Software 

• Automatic, Dynamic, Universal Z-Systems: Z3PLUS for CP/M-Plus computers, 
NZCOM for CP/M-2.2 computers ($70 each) 

• XBIOS: the banked-BIOS Z-System for SB180 computers at a new, lower price ($50) 

• PCED — the closest thing to Z-System ARUNZ, and LSH under MS-DOS ($50) 

• DSD: Dynamic Screen Debugger, the fabulous full-screen debugger and simulator, 
at an incredible new price, down from $130 ($50) 

• ZSUS: Z-System Software Update Service, pubUc-domain software distribution service 
(write for a flyer with full information) 

• Plu*Perfect Systems 

- Backgrounder ii: CP/M-2.2 multitasker ($75) 

- ZSDOS/ZDDOS: date-stamping DOS ($75, $60 for ZRDOS owners, $10 for 
Programmer's Manual) 

- DosDisk: MS-DOS disk-format emulator, supports subdirectories and 
date stamps ($30 standard, $35 XBIOS BSX, $45 kit) 

- JetFind: super fast, extemely flexible regular-expression text file scanner ($50) 

• ZMATE: macro text editor and customizable wordprocessor ($50) 

• BDS C — including special Z-System version ($90) 

• Turbo Pascal — with new loose-leaf manual ($60) 

• ZMAC — Al Hawley's Z-System macro assembler with hnker and hbrarian 
($50 with documentation on disk, $70 with printed manual) 

• SLR Systems (The Ultimate Assembly Language Tools) 

- Z80 assemblers using Zilog (Z80ASM), Hitachi (SLR180), or Intel (SLRMAC) 
mnemonics, and general-purpose linker SLRNK 

- TPA-based ($50 each tool) or virtual-memory ($160 each tool) 

• NightOwl (advanced telecommunications, CP/M and MS-DOS versions) 

- MEX-Plus: automated modem operation with scripts ($60) 

- MEX-Pack: remote operation, terminal emulation ($100) 

Next-day shipping of most products with modem download and support available. Order 
by phone, mail, or modem. Shipping and handling $3 per order (USA). Check, VISA, or 
MasterCard. Specify exact disk format. 

Sage Microsystems East 

1435 Centre St., Newton Centre, MA 02159-2469 

Voice: 617-965-3552 (9:00am- 11:30pm) 

Modem: 617-965-7259 (pw^DDT) (MABOS on PC-Pursuit) 



